I’m currently building a simple chatting web app that has 2 components. A log in page and the main page where you have one chat window where the actual activity happens.
The problem is that for my login page I use mongodb and when I login I basically just send the form data (POST) and see whether or not the inputted username and passwords from the form exist on the database, if it does I want the user to get into their account with some sort of identifier so the app renders the right things depending on the user, this component works on its own just fine. But I’m not sure how to do that with the React Router because when I integrate React Router, and I do the login nothing happens. I assume that’s because React Router intercepts any call to the server by the client. Does React Router have some way around this or am I just using the wrong tools or doing it the wrong way?
2
Answers
have you tried to use useNavigate hook or return
<Redirect to="/url" replace/>element when the response come from the server?For making back-end POST requests and such, I’d recommend using a framework like RTK Query. It isn’t the job of React Router to make such requests. React Router is used to navigate your various pages by dynamically loading the different components that compose your site as the user navigates – all without ever fully re-requesting and re-rendering the entire thing again as seen in traditional websites. Ie: React Router allows your website to function as a Single Page Application (SPA)
For authentication, I’d recommend learning to integrate an industry solution, like AWS Cognito. A common approach is to redirect the browser to the identity Provider (idp) for login. Upon successfully authenticating, the user will be redirected back to your website with an authentication code (see Authentication Code Flow). You can take that auth code and exchange it (once) for a refresh token, access token, and id token (if the scope includes openid).
The access token contains a sub claim by default. Cognito populates this with a unique identifier for the user in question. The id token can include various PII like email, first and last name, username, etc. The refresh token is opaque but can be used to acquire more access and id tokens when the others expire.
To track a user session, there are two common approaches for the front end: 1. Stick the tokens in LocalStorage (easy but less secure), or 2. Use a Secure, HttpOnly session cookie on the server-side to track the user session. In the second case, the front end JavaScript can’t read / write the cookie (hence immune to XSS attacks to directly access it) and the browser will automatically send it to the server via the headers for any request (and so vulnerable to CSRF attacks; use a CSRF Token to mitigate).
If you just have one back-end server / api for your application, then it maybe enough to let it hold onto the tokens and manage them behind the scene. Return a 401 status when the refresh token expires to let the front-end know the user needs to re-authenticate. However, if you have multiple API servers then your front-end will need the access token so you can send it via the Authorization header in your requests to your APIs. The APIs can then validate the access token each request and reject the request if the token is invalid or if it determines that the user is unauthorized to perform the action in question.