Restrict access to the authentified user - javascript

I'm creating my first application using Laravel and React.
I followed a tutorial online, and I noticed that the authentification, unlike what I was used to with only Laravel, is using localStorage instead of Auth::user.
With the following line I can get the informations of the authentified user :
const user = JSON.parse(localStorage.getItem("userData"));
I can access the info of the logged user like this :
{user.id}{user.name}{user.email}
Now in my application, each profile belong to a user.
Using react and react-routes, to access a profile, the user need to provide idof the profile in the addition of the url, like this :
<Route path="/customize/:id?" component={Home} />
The current problem is that any user can view any profil. I want to limit the privilege to see/modify the profiles to ONLY those who are related to the profiles. So when the user is logged, he can only manage his own profiles, or perhaps the profiles that have the sameuser_id as his id.
I searched and I found that I have to use Middlewares I think to manage the access, but I'm not entirely sure.


You're right, you should use a middleware to verify the user is authenticated.
I don't know which way you're using to authenticate a user.
Basically if you're using laravel built in authentication you should be able to use the default auth middleware as described here: https://laravel.com/docs/8.x/authentication#protecting-routes
Otherwise you may need to create a new middleware to handle the verification, the process of making a new middleware is described here: https://laravel.com/docs/8.x/middleware
Then you can use the middleware method on the routes you'd like to protect
Route::get('/customize/{id}', function () {
// Only authenticated users may access this route...
})->middleware('auth');
Another solution I would not recommend for this use is doing a simple Auth::check() in your controller's function

Related

Angluar modfifying localStorage data to add Roles

I want to implement simple authentication and authorization in an Angular project. I want to store a JWT token, and the logged in Users data, including Roles in the Local Storage. A routing guard service would check if the currentUser in the localStorage has the Roles required for the given route.
My problem is that if the user modifies the localStorageData, he could do some things otherwise he couldn't do. I understand that he can't make any valid requests to the server, because the sent token wasn't modified.
What's the solution for this?
Example:
https://stackblitz.com/edit/angular-7-role-based-authorization-example
Instructions:
Login with: Username: user Paswword: user
Execute in
console:localStorage.setItem("currentUser",'{"id":2,"username":"user","firstName":"Normal","lastName":"User","role":"Admin","token":"fake-jwt-token.User"}')
Refresh page

You can't prevent the client from doing whatever it wants with respect to itself. As long as your server is protected that's all you can do.

Single flow: sign user in via Google oAuth AND grant offline/server access?

I'm trying to implement Google sign-in and API access for a web app with a Node.js back end. Google's docs provide two options using a combo of platform.js client-side and google-auth-library server-side:
Google Sign-In with back-end auth, via which users can log into my app using their Google account. (auth2.signIn() on the client and verifyIdToken() on the server.)
Google Sign-in for server-side apps, via which I can authorize the server to connect to Google directly on behalf of my users. (auth2.grantOfflineAccess() on the client, which returns a code I can pass to getToken() on the server.)
I need both: I want to authenticate users via Google sign-in; and, I want to set up server auth so it can also work on behalf of the user.
I can't figure out how to do this with a single authentication flow. The closest I can get is to do the two in sequence: authenticate the user first with signIn(), and then (as needed), do a second pass via grantOfflineAccess(). This is problematic:
The user now has to go through two authentications back to back, which is awkward and makes it look like there's something broken with my app.
In order to avoid running afoul of popup blockers, I can't give them those two flows on top of each other; I have to do the first authentication, then supply a button to start the second authentication. This is super-awkward because now I have to explain why the first one wasn't enough.
Ideally there's some variant of signIn() that adds the offline access into the initial authentication flow and returns the code along with the usual tokens, but I'm not seeing anything. Help?
(Edit: Some advice I received elsewhere is to implement only flow #2, then use a secure cookie store some sort of user identifier that I check against the user account with each request. I can see that this would work functionally, but it basically means I'm rolling my own login system, which would seem to increase the chance I introduce bugs in a critical system.)

To add an API to an existing Google Sign-In integration the best option is to implement incremental authorization. For this, you need to use both google-auth-library and googleapis, so that users can have this workflow:
Authenticate with Google Sign-In.
Authorize your application to use their information to integrate it with a Google API. For instance, Google Calendar. 
For this, your client-side JavaScript for authentication might require some changes to request
offline access:
$('#signinButton').click(function() {
auth2.grantOfflineAccess().then(signInCallback);
});
In the response, you will have a JSON object with an authorization code:
{"code":"4/yU4cQZTMnnMtetyFcIWNItG32eKxxxgXXX-Z4yyJJJo.4qHskT-UtugceFc0ZRONyF4z7U4UmAI"}
After this, you can use the one-time code to exchange it for an access token and refresh token.
Here are some workflow details:
The code is your one-time code that your server can exchange for its own access token and refresh token. You can only obtain a refresh token after the user has been presented an authorization dialog requesting offline access. If you've specified the select-account prompt in the OfflineAccessOptions [...], you must store the refresh token that you retrieve for later use because subsequent exchanges will return null for the refresh token
Therefore, you should use google-auth-library to complete this workflow in the back-end. For this,
you'll use the authentication code to get a refresh token. However, as this is an offline workflow,
you also need to verify the integrity of the provided code as the documentation explains:
If you use Google Sign-In with an app or site that communicates with a backend server, you might need to identify the currently signed-in user on the server. To do so securely, after a user successfully signs in, send the user's ID token to your server using HTTPS. Then, on the server, verify the integrity of the ID token and use the user information contained in the token
The final function to get the refresh token that you should persist in your database might look like
this:
const { OAuth2Client } = require('google-auth-library');
/**
* Create a new OAuth2Client, and go through the OAuth2 content
* workflow. Return the refresh token.
*/
function getRefreshToken(code, scope) {
return new Promise((resolve, reject) => {
// Create an oAuth client to authorize the API call. Secrets should be
// downloaded from the Google Developers Console.
const oAuth2Client = new OAuth2Client(
YOUR_CLIENT_ID,
YOUR_CLIENT_SECRET,
YOUR_REDIRECT_URL
);
// Generate the url that will be used for the consent dialog.
await oAuth2Client.generateAuthUrl({
access_type: 'offline',
scope,
});
// Verify the integrity of the idToken through the authentication
// code and use the user information contained in the token
const { tokens } = await client.getToken(code);
const ticket = await client.verifyIdToken({
idToken: tokens.id_token!,
audience: keys.web.client_secret,
});
idInfo = ticket.getPayload();
return tokens.refresh_token;
})
}
At this point, we've refactored the authentication workflow to support Google APIs. However, you haven't asked the user to authorize it yet. Since you also need to grant offline access, you should request additional permissions through your client-side application. Keep in mind that you already need an active session.
const googleOauth = gapi.auth2.getAuthInstance();
const newScope = "https://www.googleapis.com/auth/calendar"
googleOauth = auth2.currentUser.get();
googleOauth.grantOfflineAccess({ scope: newScope }).then(
function(success){
console.log(JSON.stringify({ message: "success", value: success }));
},
function(fail){
alert(JSON.stringify({message: "fail", value: fail}));
});
You're done with the front-end changes and you're only missing one step. To create a Google API's client in the back-end with the googleapis library, you need to use the refresh token from the previous step.
For a complete workflow with a Node.js back-end, you might find my gist helpful.

While authentication (sign in), you need to add "offline" access type (by default online) , so you will get a refresh token which you can use to get access token later without further user consent/authentication. You don't need to grant offline later, but only during signing in by adding the offline access_type. I don't know about platform.js but used "passport" npm module . I have also used "googleapis" npm module/library, this is official by Google.
https://developers.google.com/identity/protocols/oauth2/web-server
https://github.com/googleapis/google-api-nodejs-client
Check this:
https://github.com/googleapis/google-api-nodejs-client#generating-an-authentication-url
EDIT: You have a server side & you need to work on behalf of the user. You also want to use Google for signing in. You just need #2 Google Sign-in for server-side apps , why are you considering both #1 & #2 options.
I can think of #2 as the proper way based on your requirements. If you just want to signin, use basic scope such as email & profile (openid connect) to identify the user. And if you want user delegated permission (such as you want to automatically create an event in users calendar), just add the offline access_type during sign in. You can use only signing in for registered users & offline_access for new users.
Above is a single authentication flow.

How to prevent firebase db access from chrome console or other methods

So I have a single page frontend only app. Right now I have something like this
// db.js
import firebase from "firebase/app"
import "firebase/firestore";
var firebaseConfig = {
...
};
export const db = firebase
.initializeApp(firebaseConfig)
.firestore();
in main.js I was experimenting with putting the db instance in the global window scope just to see if I could go to the chrome web console and access it to submit a doc and indeed I can
// main.js
import { db } from './db'
window.db = db;
and then from chrome console
db.collection("test").add({'somekey': 'Can I add this doc?'})
How do I prevent someone from doing this without having a real backend to check auth? I like the reactivity of vue + firebase. If I don't expose the db variable to global scope is that enough? I was reading this post:
https://forum.vuejs.org/t/how-to-access-vue-from-chrome-console/3606/2
because any variable you create inside your main.js fiel will still not be globally available due to how webpack

One of the great things about Firestore is that you can access it directly from within your web page. That means that within that web page, you must have all configuration data to find the relevant Google servers, and find your Firebase project on those servers. In your example, that data is part of firebaseConfig.
Since you app needs this configuration, any malicious user can also get this data from your app. There is no way to hide this: if you app needs, a sufficiently motivated malicious user will be able to find it. And once someone has the configuration, they can use it to access your database.
The way to control access to the database, is by using Firebase's server-side security rules. Since these are enforced on the server, there is no way to bypass them, neither by your code, nor by the code that a malicious user writes.
You can use these security rules to ensure that all data is valid, for example making sure that all the required fields are there, and that there's no data that your app doesn't use.
But the common approach is to also ensure that all data access is authorized. This requires that your users are authenticated with Firebase Authentication. You can either require your users to sign in with their credentials, or you can anonymously sign them in. In the latter case they don't need to enter any credentials, but you can still ensure for example that each user can only write data to their own area of the data, and that they can only read their own data.

User's permissions in feathers.js API

I'm trying to create some REST API with user roles like admin, superadmin etc.
I was trying to achieve this by using feathers-permissions module, but there are none working examples and the internet. Have you ever dealt with such task?
What I do now is:
feathers generate app and then feathers generate authentication. What should I do next?

The secret to implementing permissions and roles in Feathers is that Hooks really provide everything you need with all the flexibility you might want. There isn't really a a need to spend time looking for a separate module and learning it's API.
Store the permissions (which are normally just strings) in an array on the user (or a separate permissions service based on the users ID) and then in a before hook check if the user is allowed to perform the operation the hook is registered as (here the permission is called messages::create), and if not throw a Feathers error:
const { Forbidden } = require('feathers-errors');
app.service('messages').hooks({
before: {
create: [ context => {
// `params.provider` is set for any external access
// usually we don't need to check permissions for internal calls
const isExternal = !!context.params.provider;
if(isExternal && !context.params.user.permissions.includes('messages::create')) {
throw new Forbidden('You are not allowed to access this');
}
}]
}
});
This pattern can also be implemented with any existing permissions module for Node. feathers-permissions is a simple module that allows to do this more easily.
For more information also see the blog posts about Access Control Strategies in FeathersJS and Easy API Authorization with CASL and Feathers.

How to get current logged in user in react js

just wondering how to access the data of a logged in authenticated user in a react js file with node js.
In the handlebar files I have I can see information like this:
{{#if user}}
I would like to know how to do things like that in a react js file so I can assign the name of the logged in user to a js variable. Something like
var name = {{# user.name }};
Thanks in advance and sorry if I've missed something out or said something a tad dense.

First of all you need to use a method for authentication, JWT is a good bet to do so. then in your main component (app.js) send a request to a specific route (like /auth/init) to check if the user is logged (means jwt is set).
you can approach this using middlewares if you are using express.js. if the user was logged in then send the user's credentials back to the client (react) and initialize your user state with the response.
To share user state between your components you have different options. based on your needs you can choose from redux, contextAPI, or just newly introduced API hooks. read this for further perspective.

Categories

Resources