HTML/JS, login storing?

Anyone here versed in frontend dev?

I was wondering what's the best way of handling logins on a website.
So let's say the user logins through a form and the frontend makes a request to the backend and retrieves the username, pass, etc.
What is the best way to keep a user logged in, even if they refresh the site in the browser? In a single page application I guess I could store the username, etc. in an object or an array, but that would be cleared if the user refreshed the page.
I guess there's localstorage, but I don't think you can save objects there, only strings/variables.

What's the best/proper way of keeping a user logged in until he closes the browser?
 

Mr Magnus

Viking King
This is why session cookies exist. Modern web dev has also been moving to JWT which is in fact stored on the local storage. The fact that the user is logged in is stored in the session. The session token, stored in the users cookies, will act as a proof that they are logged in. When the session expires the token is lost, and so the server prompts them to log back in. If the person manually logs out the token is cleared.

There is some amount of security you can layer on top of this, but that's the general standard. Session cookies or JWT are how you retain state in HTML.

Also, if you want to store the actual data about the user then objects can be stored in the localstorage. The simplest method is simply to convert the object to a json string and save it wholesale to localstorage.
 
This is why session cookies exist. Modern web dev has also been moving to JWT which is in fact stored on the local storage. The fact that the user is logged in is stored in the session. The session token, stored in the users cookies, will act as a proof that they are logged in. When the session expires the token is lost, and so the server prompts them to log back in. If the person manually logs out the token is cleared.

There is some amount of security you can layer on top of this, but that's the general standard. Session cookies or JWT are how you retain state in HTML.

Also, if you want to store the actual data about the user then objects can be stored in the localstorage. The simplest method is simply to convert the object to a json string and save it wholesale to localstorage.
Thank you very much for the information! So I guess you don't want to store sensitive information such as user-pw in a local object or session cookie. Would a good idea be to, after user is successfully logged in, create a copy of the returned data, minus the user pw, and after that store the copy in a session cookie?
 

Mr Magnus

Viking King
I guess you don't want to store sensitive information such as user-pw in a local object or session cookie.
Correct. *optimally* you'd fetch the username directly from the server if you need it, but it's not the worst crime in the world to store it on the user's end. However storing passwords is a big no-no. As far as your systems are concerned the only time the user password exists at all is when they are typing it in to the password field and logging in. After that nobody should have any clue what it is.

Would a good idea be to, after user is successfully logged in, create a copy of the returned data, minus the user pw, and after that store the copy in a session cookie?
Generally the less information not directly asked for by the client is exposed the better, but yes. Aside from the password and potentially sensitive information you'd not want on a sticky note at the front of your computer you can store user information in the session.
 

curato

Member
the system I use at work you submit the user name and password and that generates a token that is saved locally. That is all you need is the token the server side keeps track of who that is and how long it is good for. So, you just add and auth parameter to the submission with the token in it and if it is no good then you get an error back that you need to handle.
 
the system I use at work you submit the user name and password and that generates a token that is saved locally. That is all you need is the token the server side keeps track of who that is and how long it is good for. So, you just add and auth parameter to the submission with the token in it and if it is no good then you get an error back that you need to handle.
Okay, but how do you implement such a feature in a project? Is the backend-developer supposed to handle the actual generating of the token?
I understand that once I have the token in the frontend, I just put it in LocalStorage.
BUT, the token, can I access let's say a username or user-id through that? For example, once I have the token, and want to access data from the user-id of the the person logged-in, how do I do that?
 

Mr Magnus

Viking King
When you log in the back end generates a token, yes. Then the token will be used with every request to signal to the backend "I am logged in, this is my proof".

can I access let's say a username or user-id through that?
The token optimally is a random string, complete meaningless nonsense whose only purpose is to act as a key that you hand to the server as proof that you are in fact allowed to access any given resource as a specific user. Any other information you need will need to then pass along with the token as part of the response, or you have other endpoints to fetch that information separately if you need it.
 

david.roy

Member
It is kinda a backend thing more than frontend. But basically modern JS heavy apps relying on API's will use JWT auth tokens in addition to some sort of CSRF protection. Where you store that token could be the session store, local store, or even a cookie. Though the cookie method is not ideal and you want to save that for a situation where you are migrating from a old monolithic application and need that application to be able to share the same sign in as your API's.

If you are building something new you wont need anything more fancy than the fetch API on the client end and a simple Ruby on Rails or similar backend for building the API. If you use Rails there is a gem called jwt_sessions that does most of the heavy lifting for you and presents a few standard configurations. And don't forget to setup CORS if your api is on a different subdomain from your application.

Note if you store the JTW auth in the session store it'll die when the user closes the browser. This may not be desirable by the user so a better policy is to set a expiry on the refresh token.
 
Top