You may also like...

16 Responses

  1. Tobias Dethleffsen says:

    Hei very nice article. I think there is one mistake in your article. In the overview of the server.js you have forogt the authmiddleware.
    This is the code from the complete server.js
    // get list of the users
    app.get(‘/users/getList’, (req, res) => {
    if (!req.user)
    return handleResponse(req, res, 401);

    const list = => {
    const user = { …x };
    delete user.password;
    return user;
    return handleResponse(req, res, 200, { random: Math.random(), userList: list });

    and this ist the code from the methode.

    // get list of the users
    app.get(‘/users/getList’, authMiddleware, (req, res) => {
    const list = => {
    const user = { …x };
    delete user.password;
    return user;
    return handleResponse(req, res, 200, { random: Math.random(), userList: list });

    • Clue Mediator says:

      Hello Tobias,
      I forgot to update the code in the article. Both codes will work but the new code is better than the previous one for large scale application.

      I have updated the new code.
      Thank you for drawing our attention.

      Let us know if you are facing any difficulties.

  2. Karl says:

    How do you protect yourself from login CSRF? An attacker could enter his information without the consent of the host and watch the activity of the host after. How would you prevent that?

    I really appreciate an answer of yours 🙂

    Btw, your articles are well made. It’s hard to find content right now that don’t use localstorage as a way to manage token. You are giving a full example of how to made it compare to others who tend to implement partially or in an abstract way that is hard to get for beginner in web technology.

    • Clue Mediator says:

      Hi Karl,
      In the CSRF attack, the attacker can not read the cookie because of the cross-site domain. BTW here we have implemented the demo of the login where we implemented CSRF protection after the login. You can also manage it throughout the application. It’s all depends on you that how would you like to set up your project architecture.

      BTW thank you for your kind words!

      After a lot of hard work and searching, we are able to write this article. 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!

  3. Jun says:

    Just found a goldmine. I do really appreciate the valuable resources you guys have made on this place.

  4. O says:

    Hi Clue Mediator,

    I appreciate this article! This really helped! I do have a question though — if I have another API on another server that I also want to secure. How do I ensure that with that other API, only users authenticated through this API are allowed?

  5. O says:

    Am I allowed to use this for my application?

  6. Nikola Jovanovic says:

    Heey i was wondering if you have any examples of redis implementation on the backend instead of list in memory

  7. Moj says:

    hello and thank you for your great article
    A question crossed my mind:
    When a refresh token is verified and it was expired we send 401 but the expired refresh token is still in the refreshTokens variable, so refreshTokens get bigger and bigger with expired refresh tokens which are not needed anymore! Is it correct or I’m just confused?

    • Clue Mediator says:

      Hi Moj, How you manage the store is up to you but yes it is a good idea to clear the token when it is not needed.

  8. Jack Sheng says:

    Hi – by far the best article to demonstrate the XSRF that I have found – kudos.
    QQ: why did you set the “XSRF-TOKEN” in the cookie?
    res.cookie(“XSRF-TOKEN”, tokenObj.xsrfToken);
    Isn’t the refresh token enough?

    I did not get this part.

Leave a Reply

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