I've got a React app built using react-boilerplate, and I'm unsure of the best way to deal with authentication. Here's my questions:
If a user authenticates, their token is stored in localStorage. If they leave the app and come back, state is cleared, so I'll have to grab their profile picture and such again, as well as check expiration/validity of their token by pinging the server. Where do I do this? Doesn't make sense to add this to EVERY route's onEnter function.
On each subsequent route change, data will obviously be fetched from the server. Each piece of loaded data on the page (maybe it's graphs, products, account info, whatever) will authorize the user since the token is sent in the header of each request. If one or all of the routes come back as unauthorized, do I redirect them? Make the whole page render an error? Just show an unauthorized error on the one/many sections that were unauthorized?? Not sure how this works.
Related
I have React signIn form and sessions mechanism implemented in NodeJs. In React I have protected routes only for authenticated users.
How should I check if user is authenticated. I have two ideas:
If user sign in for the fisrt time I can save this information in LocalStorage and then evrytime just check localStorage.
Send request to NodeJS server every time to check if user is authenticated.
Do you have any other ideas? Which solution should I pick?
I tried both options and second one is more UI unfriendly becasue I have to run loading state evrytime I am waiting for auth response. On the other hand, first option has also disadvantege, because I am based on token in LocalStorage which can be malicious.
Every time a request is made to an endpoint that requires authentication, the request should contain proof that they are who they claim to be.
The classic way to do this is by storing some sort of "Session ID" in a cookie or localStorage (client side), that you send along with every request.
Using a "Token" (e.g: JWT) instead of a "Session ID" is another popular way to handle authentication.
Check out this article for more information about both: https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide
To return to your question, I'm not sure what you're worried about in regards to a "malicious Token in localStorage" (Or do you mean localStorage can be malicious?). But for a secure application you have to either:
Store something client-side
Require your user to provide credentials (username + password) for every request
in nuxt.js we can use nuxtServerInit and call backend api only once for a page reload. After that it doesn't run. So its a best place to get one time data server side like getting authenticated user details and storing it in the store. After that one load, you don't have to worry about the auth user. Is there anything like this in next.js?
I have an application that uses express.js as the server side language and React on the front-end. I use passport.js to authenticate routes in the server, using local login and facebook strategies (no JWT). I use express-session to manage the session, which seems straight forward ( or insufficient, which I do not know yet, for my case, as its work in progress ).
My requirement is to hide/show few links in the Header component.
i.e.,
Log In
Sign Up
should show up in index page, when user has not logged in, but hidden when he is logged in. Likewise, few links should be hidden when the user is not yet logged in.
What is the best wat to check this from the client? Making an AJAX call is not ideal, as I may have more use cases of checking if the user session is valid from the client.
I can see the default connect.sid cookie, which the express creates, but how do I make use of it, or is there a best way for the client to know that the user is already logged in.
You have a couple options. Here are some:
You can check for the presence of a different cookie in the browser, and use that as your metric for whether or not you are "logged in". Your browser won't know if the session has expired server side, so you still have to account for the fact that you may be logged out and not know it. Additionally, you have to be sure to clear this cookie when logging out and set it when logging in.
When starting, your browser can make a AJAX request to get the currently logged in user. This might be useful for all sorts of things, such as displaying the user's name when logged in. You really only need to do this once (on page load and on login), then keep track of the user's login state stored in memory. You mentioned you don't want to do this, but it is fairly common.
When loading the page, you can inject the user into the page. For example, when the page loads there will be a <script> tag containing window.currentUser = null or an object representing the user. You can use this to "bootstrap" the login state without needing an AJAX request.
To clarify, you can't use the connect.sid cookie by itself because this cookie is just the ID of the session, not the session data itself. Only the server knows the session data that's being stored for that user, not the client. You need some way aside from this cookie for the server to tell the client that it's logged in, and the client to keep track of that state.
If you want the client to know from the ID component itself, you'll want to look at token options like JWTs.
I’m trying to figure out a React app using JWT for authentication, I dont’t really know how to plan it, for example:
Step 1: The user successfully logs in the app, gets a JWT token that is saved on localStorage.
Step 2: As soon as the user is logged in, the route changes and a request to the REST API is made, the request is authenticated using the token previously saved. The fetched data is now on state.
Step 3: The app has other routes that actually just filters the previously fetched data, so I think making new requests just to check auth would just makes things slower for no reason.
I would like to know a good practice to handle that, maybe check auth after a certain amount of time. Or the right thing to do is make requests on every route change just to check if the user is still authenticated?
The app has other routes that actually just filters the previously fetched data
make requests on every route change just to check if the user is still authenticated
If the user already has the data, it makes no sense from the security point of view to re-authenticate for the same data. Only re-fetch if you need to make sure the data is updated when the route changes.
I have a scenario where login and logout API's from third party service provider. Redirection to the above API's call happens in my web layer(using Spring) based on the available cookies and using Angularjs as front end.
Coming to my question, How can I redirect to previous Angular state after log-on into my application once user hits logout.
You can go about this two ways that I can think of. If the data is simple enough, you can add it to the url as a query parameter. If it is more involved, then you may want to look into using local storage. You can save the state to local storage, and then retrieve it when you get redirected back into the app. There are some edge cases you will have to consider, but that should work for you.