I have a react/laravel app that currently uses a variable stored in the localStorage to do routes protection.
When a user is authenticated on the server side, front end saves a variable logged-in to true in localStorage. In react, on route enter, it checks if logged-in variable is set in localStorage. if not, redirects to login component.
The problem is that user can just modify their locaoStorage with javascript or in their js console to cheat the UI authorization.
So how should i go about preventing this? Or is there a better approach to protect routes in react? Thanks.
Related
Well i am new to React. While developing a simple website i came accross an issue. I used a isLoggedin variable in React app to check if it is true then the user can access the whole website otherwise he will remain in the login page. But when i came to know that my isLoggedin variable can be easily changed from client side to true, so how can i secure my webite that only the logged in user can access it? How make isLoggedin variable secure?
Note: isLoggedin is a state variable.
And my frontend is connected to a nodejs backend. When a user login I sent a request to backend to verify and return a token. After receiving the token i make isLoggedin to true. Thats my logic.
I'm currently using a NodeJS server. I verify a condition with a if statement. If the credentials are not valid, for example, how to send the user to a specific page?
if (credentials) {
// go to the main page
}
else {
// go the login page
}
You've said you're using ExpressJS. In ExpressJS, you do a redirect via res.redirect:
res.redirect([status,] path)
Redirects to the URL derived from the specified path, with specified status, a positive integer that corresponds to an HTTP status code . If not specified, status defaults to “302 “Found”.
First, you need to establish what kind of authentication you are using. There are a million ways to do this, but if you are less familiar with auth systems, I would recommend using a third-party auth system like Facebook or Google login. Those would generally give you some kind of auth token on login, and essentially you could just check to see if the stored token is there, whether that be in cache, cookies, local storage, etc., and if it has not expired. If all is good, keep going, if not, then redirect to the login page.
If you want to make this more secure, don't write any of credential validation on the client side. Have the client's browser check for the auth token and its recency, then send it to the server. The server would then respond by routing you to the proper page.
Another method that should probably be used in tandem with this would be to check for a valid login on every single page where the user would need to be logged in, as opposed to only having the one page that redirects to either a login screen or where you want to go.
I'm working on a React application. I am defining user roles and restricting access to components based on the permissions level of the role. I am looking in to using signed cookies to set the permissions from a php backend. When I determine whether the application should render a component based on the data in the cookie, how do I verify that the roles in the cookie have not been redefined by the user without sending the cookie to the backend?
That's not the right approach, in my opinion. The components should be free to load - if there's something built-in to a component that an un-authenticated user shouldn't be able to see, there's nothing stopping someone from going into the source and discovering it themselves.
You have to take a different approach for front-end applications - all the components and UI are public. When the component fetches information from the server to display to the user, the server will still do the session authentication and respond with a 4xx (401 would be a good place to start) and the component would handle that response appropriately.
If modifying the role in the cookie would allow the user to gain more rights, then the solution is not to check the validity of the cookie on the client side. The user could also modify the client side script to circumvent/skip the integrity check of the cookies, and you would have the same problem as before.
The only correct solution is, that the user won't get those informations/scripts at the first place. So you need to check on the server side what informations are allowed to be send to the client, only send the data the user is allowed to see, and verify all actions the user sends to the server on the server side before you execute them.
I've been able to successfully setup multiple Ember applications with shared Ember Simple Auth cookie based authentication. The next step of my journey is to setup proper redirects between applications. Hear me out.
Scenario A (this works out of the box, yay!)
User tries to access domain.com/deep/link/resource
User is NOT logged in
User is redirected to domain.com/login to login via single sign-on component that uses Ember Simple Auth to save cookie with token
After successful login user is redirected back to domain.com/deep/link/resource via previous transition
Scenario B (this works out of the box, yay!)
User tries to access app-b.domain.com/deep/link/resource
User is already logged in via Ember Simple Auth cookie with token
User can access app-b.domain.com/deep/link/resource route
Scenario C (this is what I need to achieve)
User tries to access app-a.domain.com/deep/link/resource
User is NOT logged in
User is redirected to domain.com/login to login via single sign-on component that uses Ember Simple Auth to save cookie with token
After successful login user is redirected back to app-a.domain.com/deep/link/resource via previous transition on app-a subdomain
Any help or guidance would be much appreciated. I wonder if I can achieve Scenario C with Ember Simple Auth only, or if I need to write custom redirect logic in beforeModel on subdomains, etc.
You'll be able get scenario C working by overriding the AuthenticatedRouteMixin's beforeModel method. That will by default to an (Ember.js) transition to the login route but in your case you want sth. like window.location.replace('domain.com/login') and remember the current URL in a cookie or so. In order to redirect to app-a.domain.com/deep/link/resource after the user logged in you'll need to override the ApplicationRouteMixin's sessionAuthenticated method so that it redirects to the previous URL remembered in the cookie if that's present and falls back to the default behavior if not.
Overall, getting this to work should be pretty straight forward actually following these steps.
I have several web pages that should work only if certain condition is true. For example, there is a registration page, a login page. If someone is already logged in, I don't want the user to login again or register again until he is logged out. Currently the server saves the login in a SESSION variable and each web page has to called the server to get the SESSION variable and determine whether to display the page or not. This does not seem like a good solution. I am thinking may be saving in on the client side, but I don't know a good approach. Should I use cookie for this ? Is there some other services on the client side to store session data ?
Cookies are the best option for session details involving login, any other persistent storage should use localStorage.
This is because cookies will be transferred to the server on each request and therefore can be used to authenticate each call.
If your confused about this sort of stuff it can be very dangerous for your site. Try read up on it and try to use whatever the standard is for your language/framework/library.