1

I am using my building journey to learn web development. I'm using nodejs, reactjs, mongodb, axios and expressjs. Currently, I'm storing basic user details such username, id, role,email in the local storage. I could store other things as I continue. However, along the line, I felt that storing something like role in the localstorage could be problematic since anyone can edit their localstorage. This means, user can easily edit their local storage and change their role to admin to have access to what admin has access to.

I decided to visit some known websites like Upwork, etc, I checked my localstorage and I noticed that they didn't store information such as username, email, role, etc. As someone new in this field, where do you think is best to store information such as the above I mentioned, especially data that can grant access and change access privileges of any user? I don't think localstorage is best for this at all. Also, while inspecting the browser developer tool, I noticed that whatever one passed from the response from backend is also seen under the response section in the web developer tool. Is that response section accessible by Javascript? Or it is already encrypted by expressjs?

kinhs
  • 175
  • 13
  • Ideally you should store the username, and email in a JWT(https://jwt.io/introduction) which you can keep in local storage(it is cryptographically signed to keep the user from changing the values). I would store roles on the backend(and even if you have a role stored in the JWT, verify it before granting privileged access). – ruby_newbie Mar 28 '22 at 17:59
  • Thank you for your answer. If I store user role in backend, how about when I want to render certain pages in react js based on user roles? How would that be accessed while using axios to call the api? – kinhs Mar 28 '22 at 18:09
  • You would pass in the JWT to the call to the API. The backend will unwrap the JWT, find the user, verify the role, and return the appropriate content. Does this help at all: https://stackoverflow.com/questions/56004504/how-to-implement-role-based-restrictions-permissions-in-react-redux-app – ruby_newbie Mar 28 '22 at 18:13
  • Thank you so much. This is really helpful. I guess when I checked my localstorage for some websites, I saw tokens too only. Now I understand what they are doing. I will use this method. – kinhs Mar 28 '22 at 18:16
  • Thank you very much. I checked the link you shared, but seems I didn't get clearity on the react part. Now, I perfectly understand how I can use jwt to implement this and the server would handle checking for the role. However, what of react rendering a page based on roles? Let say I have a page login which only shows if user is verified and and role is user. And I didn't pass role and isVeried into jwt payload. How best do one handle this since rendering pages don't make api calls? They are simply pages built in react. And sincerely, it is not best passing role and verired in jwt payload. – kinhs Mar 28 '22 at 20:30

3 Answers3

1

There are two concepts here which are important to understand: Authentication and Authorization.

Authentication is the process by which the server will validate that the user says who they say they are. The most common example of authentication is username and password.

Authorization is the process by which the server will validate the user can perform the action they want to perform. Once the user is authenticated, they will usually look up the user in a database and see if the user as the rights to do this (in your example, once such right could be admin).

For your example application, you could probably do something simple like store the username, a hash of the password and the user role in a table in your database. That would probably be good enough for your learning. When a user is trying to access something, look up the role in the table and if they don't have permissions to, return a 403 Forbidden

But you are just scratching the surface of the topic. For example, you said that applications do not store roles on the client side, but interestingly if you're using something like Json Web Tokens, this information will be on the client-side. In this flow, you authenticate to your service, you get a token that contains your role (admin in your example) and a signature. The signature is used to validate that the token was emitted by the service, meaning that the role it contains can be relied on. So when your application makes a request to your service, your service will only need to validate the signature.

Etienne Martel
  • 73
  • 6
  • Thank you for your answer. I think instead of adding username, email, etc and access token to the response which I got from jwt, I should simply send back jwt access token that has those information. Keep the access token in frontend and write my backend to always verify the access token before performing actions? – kinhs Mar 28 '22 at 18:14
1

I was once in your shoes, trying to figure out what to use when, when working with the same tech stack as yours. Let me tell you now what I use-

  1. Decide what do I want(if it is a small application that needs to be built rapidly with all functionality I use sessions ( nodejs provides an excellent library known as express-sessions ), if I want a detailed fast app, I use JWT.
  2. When you want to store things user settings of volume, light-mode dark mode, you can use simple local data storage.
  3. If you are receiving data on the frontend side and want to use it there, you can use state-management frameworks like zustand, redux, or any others. Further detail on the question -> you can modify what you store in the session like username, email-id, and all that, and as more data is needed you can request from the database once the user is verified. If you have more specific questions to ask, feel free to fire on me, I will try my best. Upvote if it gave you some insight on topic.
prasoonraj
  • 90
  • 9
0

Never store important information on localstorage. Your intuition of it can be changed or it can be accessed by someone else is correct. And even if you store some data (such as jwt tokens) never trust your front end and validate it with the backend server for data retrieval.

In your case you can use session storage or cache storage depending on how to store the data that you need

HexaCrop
  • 3,863
  • 2
  • 23
  • 50
  • Thank you very much for your comment. I already wrote a verification middleware that verifies the token per api call. Where best can I store user details like name, id, email, role for frontend to access for page rendering and others? For instance, when a user makes a post, their name displays on the post, the frontend needs access to the name and stores somewhere the frontend would access to display the name of the user. The same thing with role. Some pages are only for admin. How would the frontend have access to user roles if not sent from backend and stored somewhere in frontend? – kinhs Mar 28 '22 at 22:16
  • I'm really interested in knowing the best place to store such information for the frontend to use. I'm not talking about server side checks now. That one has been sorted out. I'm talking about data that the frontend needs access to for page display, date display etc. – kinhs Mar 28 '22 at 22:17
  • you can use session storage API – HexaCrop Mar 30 '22 at 16:49
  • I have updated my anwer – HexaCrop Mar 30 '22 at 16:51