You may also like...

14 Responses

  1. Thomas Jennings says:

    What keeps someone from sniffing username and password in axios.post(${API_URL}/users/signin, { username, password }); ?

    • Clue Mediator says:

      Hello Thomas,
      If it’s easily possible then no one will use REST API. If you have any idea about it then please share with us.

      We will enjoy learning new things. 🙂
      Thank you!

  2. Thomas Jennings says:

    Thanks for the response. And also thanks very much for all these articles! After doing some more reading I guess the best answer to my question would be to make sure to use https, that way the username and password would be encrypted going across the wire.

  3. Col says:

    As the security related infos are basically stored inside Redux store, the token only persists as long as the session (bowser) is running. However, when the browser is closed, all the infos are gone thus, If I want to make ‘stayed sign in’ feature, do I have to store the Token info inside Cookies as well as helper functions or other means to refresh the token outside of the browser

    • Clue Mediator says:

      Hey Col,

      You can see here, we are storing the refresh token in cookies to perform the silent authentication.

      So when we are reloading the page then we will use these all details to get the basic user information before rendering the component. Please check out the working demo and output for more details.

      Feel free to share your thoughts.

      Subscribe us for weekly updates or like and follow us for regular updates.

      Happy Coding..!!

  4. Romil LODAYA says:

    This post helps a lot. I have two questions
    1 – How to handle verifyTokenTimer() commonly when we have more pages. As we are making repetitive code in each file.
    2 – When I am calling login it gives me a response in the Network tab with Set-Cookie but not in COOKIE inside the application tab.

    • Clue Mediator says:

      Hello Romil,
      Please find your answer below.
      Ans1 – You can use that method in the root level of the private route or you can create a custom effect and use it at multiple places.
      Ans2 – Can you please clone the repository that we have provided and check it in your local system?

      Subscribe us for weekly updates or like and follow us for regular updates.

      Thank you!

  5. Szymon says:

    Hey, great post! Thanks for that but i have question. As it is described at OWASP recomendation: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#use-of-custom-request-headers
    “CSRF tokens should not be transmitted using cookies.”
    So how safe is to send it via cooke from server and then send it back to server also as a cookie? (I know it’s in header but its still in cookie also)

    • Clue Mediator says:

      Hi Szymon, As we researched on CSRF tokens, we can’t find a way to manage CSRF tokens without cookies in SPA.

      If you have any feedback for this approach (good and bad), do let us know in the comments. So we can share it with all other readers.

      Thank you!

  6. Moj says:

    Hi,
    I’m so grateful for your detailed and complete article.
    In “asyncActions/authAsyncActions.js” line 20, when we get status code 204 it means that the browser didn’t send the refresh token to server (maybe user deleted cookies or sth else). In this situation, why we don’t logout the user just like when we get 401 or 403 status codes?

    • Clue Mediator says:

      Hi Moj, For the status code 204, we don’t need to execute the logout method because we verify the token on page load if exists.

  7. Mary says:

    Hello
    The concepts and explanations of secure rest api in your article are fantastic and I really appriciate that. I know that the main goal of this article is implementation of an acceptable authentication but there is a risk of infinite re-render loop in your react codes:
    Let’s say that after signing in, we render the dashboard component and call getUsersList on page load. And let’s assume that there is a problem in our request and we get status error 400 (bad request). In this case we get result.error in line 28 of dashboard.js and we only dispatch verifyTokenEnd but we don’t logout. Consequently, we change “authLoading” state and this change causes App component to re-render. App component re-renders and as a result dashboard component renders again. So getUserList gets called again and we get error 400 again and the loop continues infinitly.
    As I know in react when we change the state of a parent component in it’s child we cause an infinite loop of re-rendering. This is because of the fact that when a parent component re-renders, it’s child components renders again as the first time and dependency array of useEffect in child component is useless in this case.
    This is All I know, but I do not know how to resolve this problem in your code!!! Is it OK to move line 28 (in dashboard.js) inside of “IF” block (in line 29) just before logging out? And then after the “IF” block we manage the 400 error code independently? So in this case, If we get error 400 we don’t dispatch verifyTokenEnd. Is this a good solution?

    • Clue Mediator says:

      Hi Mary, I will suggest you to manage the HTTP interceptor for your API request where you can handle all API request-response. But it’s not a good idea to perform the logout operation on status code 400.

      Let us know if you have any queries.

Leave a Reply

Your email address will not be published. Required fields are marked *