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.
Related
I am using PHP, AJAX, and JS for my PWA development. I want the user's logged-in state to stay persistent when he/she come back to the PWA app.
Right now I am doing it via the help of the Access token and saving it in the cookie with HttpOnly via PHP. Defining it here -
User enters details, and log in to the app.
That details sent to the PHP backend, via AJAX.
Backend login code check that details from database and if matched, then code create a random hashed token.
Backend code save that hash to the cookie with HttpOnly and secure flag.
User then prompted with a successfully logged-in message.
When the next time the user comes back to the web app, the server PHP code looks for that login hashed value saved in a cookie and finds the relevant user from Database.
If a match found, the user successfully logged-in.
So now my concerns are -
Is this whole process secure and the same as what gets implemented in Industry.
If not, then what can be the best way to achieve this with security.
You can find the answer you are looking for here:)
"Keep Me Logged In" - the best approach
It is important to use an hashed cookie.
On the client side you should use a cookie that represnting the "id" of the "hashed" cookie,
When the next time the user comes back to the web app -> you will check his cookie("id") with the hashed cookie you saved on the server and check for a match(done on server side).
Note: the hashed function is done on your server.
One more thing: never let that cookie(hashed) leaves the server.
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'm trying to make a basic social networking application following Write Modern Web Apps with the MEAN Stack book.
The end result should be: https://mean-sample.herokuapp.com/
I got through to getting user accounts set up, having a user log in and create a personalized post. But as soon as I refresh, the user gets logged out.
What am I doing wrong? And how do I fix this?
In the client side we cant maintain the session, we need the server support to it. There are many ways to maintain the session
1 Token based, for each request to the server, the server will check whether token exists or not.
2 We can store in the localstorage while refresh the rootscope will be, at that time we can take from local store and populate the page objects.
Maintaining in server side is secured and advisable.
use localstorage, it will help you in maintaining the session and also store user details temporarily.
Refer this for more details
https://github.com/grevory/angular-local-storage
I have an angular.js single page app that authenticates against a RESTful API (Servicestack). This all works fine. When the response from the authentication api is returned the username is stored on an Angular service and an isAuthenticated flag is set to true.
Any requests against an [Authenticate] attributed web service then returns data.
My issue is that when I refresh the browser my javascript angular objects are flushed and the fact the user authenticated is forgotten. Yet when I call the [Authenticate] attributed service they work correctly because the session is still live...
Apologies for the rather noob question but how does the browser pass the session to the web service when the javascript objects have been destroyed and recreated? How do I grab the same session on refresh and set my Angular service up with the username etc.?
ServiceStack Authentication uses cookies to store the session token by default. Which means your Angular application will receive the cookie when you first sign in. It will pass this for subsequent requests, and they will succeed while the session is still valid on the server.
The problem will be that Angular will lose the object state, when you refresh the page, that is telling it you have an active session. So you must restore this knowledge to Angular. There are two ways to tackle this:
Check for the ss-id cookie when you application starts and assume you have a valid session. In other words, so restore to a signed in state, until you get a 401 error from the server. This is the quickest approach, and doesn't require additional overhead to check the session if somebody refreshes the page.
Check for the ss-id cookie and make a test authenticated request to check the session is still valid.
If you need to restore other information such as the current logged in user's name etc, then you would need to store that in a cookie/local storage to restore it on refresh, or go with method 2, and retrieve it back from the server.
You can use $cookies provider to manage the session cookie.