I'm trying to understand how most online websites authenticate and then store your session. What I'm particularly trying to understand is when I log into a website it starts off by redirecting me to the login page and then validates my username/password, then navigates back to where I started but with my information displayed. If I were to navigate away from that webpage and then come back to it sometime later I'm still logged in. I feel like this is what a cookie could be used for but I'm looking to see if anyone could provide me with a good explanation as to how this works?
A cookie is a bit of data stored by the browser and sent to the server with every request for instance a subscription status on a website.
A session is a collection of data stored on the server and associated with a given user (usually via a cookie containing an id code)
Session values are reset after the connection is closed. Cookies values are normally saved.
Session values are usually reset after a period of time has passed without a connection from the client with which the session is associated. Cookie values are saved until their expiry time (or the browser is closed if one isn't set). Expire immediately overrides are available for both
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.
Supposedly, I am not using HttpOnly cookies for my session on a PHP web app. If a visitor is on a page that uses PHP sessions, they can see the session cookies. In addition to viewing, they can also delete or edit it.
The next case involves the user being on a page (say, normal page) on my web app that doesn't uses sessions and the normal page contains a link to a page which uses sessions (session page), having, session_start(). On the normal page, if a cookie is set (say using the console) with the same name as the one I use for session page, and the click is made on the link to the session page, what happens when I do session_start() on the session page?
Does it create a new session, or tries and map to a session with the value in the cookie being sent from the normal page?
If it maps, to an existing session value, then the session is said to be hijacked. What happens in the case when it doesn't map? Does it create a session cookie with a new value?
Even if I use HttpOnly for my sessions, it is sure that the session cookie cannot be read or manipulated using JS on the client side. But on the server, does the server read the same (HttpOnly) on the session cookie being sent to the server by the client and invalidates the session, in case it wasn't HttpOnly? Or does it try to map the value to existing sessions on the server?
Hope I was able to make it clear.
Sessions work in PHP like this.
When the user first visits the site and the PHP has session_start() it checks if the user is sending a cookie with a session ID. If they aren't then it creates one and sends it so the user stores it in a cookie. Then when the user visits another page session_start() can check if they already have a cookie and this time they do. Session cookies (stored on a user pc) are cleared when the browser is closed.
session_start() isn't creating a new session every time it is called. What it is doing is pulling in information about that session so it can be used further down in the code. When the user sends the session ID from their cookie, session_start() then pulls in the information stored about this session from the web server so then you can do things such as if you stored adminloggedin as true or false in their session. If the user didn't send a session ID then it doesn't pull any information from the server and just creates an ID and sends this back to the user to store in a cookie.
You don't need to use session_start() on every page however if you needed to check something from a users session such as if they are logged in then you need to call it in order to get the data about their session.
All information about a session is stored server side. For example, if I said the user was logged in and stored this in the session then this can be checked to allow access to admin pages. The user cannot fake this as all they are sending is the session ID and all the data about the session is stored server-side. They are not storing a cookie with information about the session, all they store is the ID for the session which is sent across.
I am new to web development and I am trying to implement log in functionality. I have successfully implemented the log in functionality. When I open www.bla.com/login I am able to log in post which gets redirected to the homepage.
Problem: If open another tab and type: www.bla.com/login it again opens login page. Ideally if I am logged into one of the tab, I should be redirected to homepage irrespective the url being pointed to login page.
P.S: I am not sure what chunk of code I need to share here because I am not sure what causes this issue. Please help or let me know if I need to post my code base. I am using JavaScript and backbone as front end.
EDIT
I have a REST Service which gets hit when I login and REST service gives me back a User Specific Token. I use this user specific token to again call another Rest Service to fetch more user specific data.
So, basically I need to put a check on this token received. The token received I have stored in browser session. But when I go to another tab and try to access that token its NULL. So I am assuming every tab in browser does not share the session storage. If Yes, then where shall I place this Token so that if someone hits the login page I should check whether a token already exists. if exists then redirect to home page. Kindly guide.
It is hard to say without seeing your code, so let me make an educated guess:
Most likely you do not create cookie with some sessionId after user is successfully logged in.
This cookie would be then used in every request sent to the server, to prove that user is indeed authenticated.
When you open a new tab and there is no cookie/session created, than this new instance of application has no knowledge of the other instance, where user is already logged in.
You may want to look at this answer
EDIT
Maybe you are using sessionStorage instead of cookies. At least I would say so, when I read about behaviour of your app.
See the docs for session storage
The sessionStorage property allows you to access a session Storage
object. sessionStorage is similar to Window.localStorage, the only
difference is while data stored in localStorage has no expiration set,
data stored in sessionStorage gets cleared when the page session ends.
A page session lasts for as long as the browser is open and survives
over page reloads and restores. Opening a page in a new tab or window
will cause a new session to be initiated, which differs from how
session cookies work.
So make sure that you application store the token either in cookies or in localStorage. And also that it correctly reads from them. Maybe the cookies is created, but never read?
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.
If there is a timeout set on one of our pages, and that same page is opened in another window/tab, is there a way to destroy/stop the timeout in the other window? We have employees who will use our system but open it again from their favorites. If they do this the already opened window will run the interval and then timeout. So while they are working in the new window they opened they will not be able to finish what they are doing because the other window timed them out.
Are there solutions to do this if a new window is opened?
In any sane web application, it is safe to have multiple windows open – especially in respect to session timeouts, because "session" state is managed by the server, not the client.
First, consider why web servers manage session state. HTTP was designed as a stateless protocol, which means any given request cannot conclusively identify who issued the request. This is fine for serving static resources, but is obviously not useful if we want to develop a more interactive app; Netscape later added cookies to their browser to address this.
Cookies solve the state problem (since the browser will issue consequent requests with the cookie[s]), but they are inherently insecure: a malicious client could modify a site's cookies. If, for example, upon login we set a cookie called uid to the user's ID, it would be trivial for someone to fake a cookie with uid=1, which might be your site's administrator account. Oops.
This is why web application frameworks invented the "session" construct. Each time a request is made with no cookie, the server creates a new (random) session key and sets the client's session cookie to that key. The web server keeps track of sessions and all state associated with each session. Important here is that the key itself contains no data, is large and random enough (has relatively high entropy), and is useless outside of your server. It is thus not possible to know how to change the key to gain access to other sessions.
Think of sessions as a large array – one item for each session, and a map of variables in that item. Conceptually, it might look something like this: (remember that this data resides on the server!)
session['safa4fwsa34rff4j9'] = { uid: 1, ... }
session['ajiokinmoi3235000'] = { uid: 4312, ... }
session['9lij34fff032e40k0'] = { uid: 9098, ... }
If I was signed in as user 1, my browser would send a cookie with sid=safa4fwsa34rff4j9. The server looks up this session, and passes the saved state ({uid:1}) on to your scripts. When your scripts are done, the server saves any changes back into its data store. (Session data is often kept in-memory, but in large sites, session data can be saved in a database.)
So what does all of this have to do with timeouts? This session data cannot be kept indefinitely because you'd eventually run out of storage space (whether that means running out of RAM or filling up the database your sessions are stored in).
Instead, the server also stores an expiration date & time with each session. Each time the session is accessed (by a client sending a request with the session's key), the expiration date is reset. The expiration date can be set anywhere from a seconds from now to years from now (depending on what server you're using). You configure how long you want your server to hang on to sessions; IIS defaults to 10 minutes, PHP to ~24 minutes.
In this model, the only thing that really matters is the last time a client issued any request, thus resetting his session's expiration/timeout. It wouldn't matter if multiple windows are open, because as long as one of them have accessed a page recently, all windows will still be active. If the session expires, then all windows are automatically expired when they make their next request.
Something that might muddy this issue is if you're doing some kind of AJAX polling, but the question doesn't indicate what technologies are being used. (#OP, it would be helpful if you included tags for your server stack.)
To summarize all of this: If you're doing any kind session management/expiration on the client, you're doing it wrong. Your app is likely insecure.