3 ms·

I agree with all this, though if you're deadset on React (which is a great choice) and you know JS well, then I'd say Express is a better choice than django. A

I agree with all this, though if you're deadset on React (which is a great choice) and you know JS well, then I'd say Express is a better choice than django. Also > Do not use jwt I heavily disagree with this. JWT has its trade offs sure, but if you want to start simple and have the most "cookie like" experience then use cookies and store your JWT inside the cookie. Edit: To be clear, to get started you should use whatever auth your web framework of choice provides which is usually some "randomly" generated token that gets written to the db and to a cookie which works fine. However, if you need to customize it or if for some reason you're making your own auth system (not advised) you should make the token that goes into your cookie a JWT instead of a random value

deleted 8y ago
[deleted]
eximius 8y ago
What is the purported benefit as opposed to a shorter cookie that is the key for an expiring record in redis that contains whatever session information the JWT would have? And it scales... The JWT would just continue to grow in size and increase request response size... And you'd have TWO expiration dates (on the cookie and in the JWT).
- shadowmint 8y ago
  This. JWT is a pain in the ass for a lot of reason people don’t appear to understand until they actually try to use it; and the majority of the proponents for it appear to have never actually used it seriously and had to deal with issues like, oh wow, redis is now the bottleneck for my ‘stateless’ authentication. Unless you need it and can articulate why, with no magic hand waving... just. use. cookies. ...and ffs, dont just put your jwt in a cookie, thats stupid...and if you don’t understand why, you shouldn’t be using jwt.
  - edude03 8y ago
    I think you are confusing the technology with the implementation here. JWT the technology is essentially a way to issue a token and validate that the token is legimiate. No one said anything about stateless authentication. If you're going to use cookies, and I recommend that, you need to put something in the cookie, cookies don't magically implement authentication for you. If for some reason you're not using the framework's way of authenticating with cookies, I'd recommend using JWT. Is there something else you'd recommend? Just use cookies is a hand-waving answer in and of its self.
    - eximius 8y ago
      And you don't understand the purpose of JWTs. No one needed to mention anything about stateless authentication because enabling stateless authentication is the purpose of JWTs [1]. Yes, just store a signed cookie with a random token for the session and use stateful authentication. That fits most people's needs better than stateless. (Even signing is more or less optional in many common cases. If the cookie is only a sufficiently long random token for the session key, then I don't really care if a user changes it, they'll only log themselves out.) [1] - https://jobs.zalando.com/tech/blog/the-purpose-of-jwt-stateless-authentication/ https://jobs.zalando.com/tech/blog/the-purpose-of-jwt-statel...
- edude03 8y ago
  Well, you're making a lot of assumptions already about how the stack would be implemented. I'm fairly certain most frameworks store session information in your main DB (postgres, mysql) and adding redis would be an enhancement. Secondly, why would the JWT continue to grow? It (should, in this case) only be used as a standard way to validate that this cookie is legimate and signed by the server.
  - eximius 8y ago
    > Secondly, why would the JWT continue to grow? I replied to your other comment more completely, but thought this part was worth answering as well. If you are using JWTs for stateless authentication/authorization, you need to include the identity (which doesn't grow) AND the list of authorizations (which might grow). And, even if it doesn't grow, JWTs are quite large compared to the HMAC of a random token. HMAC size: 64 bytes, JWT size: several hundreds of bytes, easily a few kb, if we put more than the bare minimum.

deleted 8y ago

[deleted]

eximius 8y ago

What is the purported benefit as opposed to a shorter cookie that is the key for an expiring record in redis that contains whatever session information the JWT would have? And it scales... The JWT would just continue to grow in size and increase request response size... And you'd have TWO expiration dates (on the cookie and in the JWT).

shadowmint 8y ago
This. JWT is a pain in the ass for a lot of reason people don’t appear to understand until they actually try to use it; and the majority of the proponents for it appear to have never actually used it seriously and had to deal with issues like, oh wow, redis is now the bottleneck for my ‘stateless’ authentication. Unless you need it and can articulate why, with no magic hand waving... just. use. cookies. ...and ffs, dont just put your jwt in a cookie, thats stupid...and if you don’t understand why, you shouldn’t be using jwt.
- edude03 8y ago
  I think you are confusing the technology with the implementation here. JWT the technology is essentially a way to issue a token and validate that the token is legimiate. No one said anything about stateless authentication. If you're going to use cookies, and I recommend that, you need to put something in the cookie, cookies don't magically implement authentication for you. If for some reason you're not using the framework's way of authenticating with cookies, I'd recommend using JWT. Is there something else you'd recommend? Just use cookies is a hand-waving answer in and of its self.
  - eximius 8y ago
    And you don't understand the purpose of JWTs. No one needed to mention anything about stateless authentication because enabling stateless authentication is the purpose of JWTs [1]. Yes, just store a signed cookie with a random token for the session and use stateful authentication. That fits most people's needs better than stateless. (Even signing is more or less optional in many common cases. If the cookie is only a sufficiently long random token for the session key, then I don't really care if a user changes it, they'll only log themselves out.) [1] - https://jobs.zalando.com/tech/blog/the-purpose-of-jwt-stateless-authentication/ https://jobs.zalando.com/tech/blog/the-purpose-of-jwt-statel...
edude03 8y ago
Well, you're making a lot of assumptions already about how the stack would be implemented. I'm fairly certain most frameworks store session information in your main DB (postgres, mysql) and adding redis would be an enhancement. Secondly, why would the JWT continue to grow? It (should, in this case) only be used as a standard way to validate that this cookie is legimate and signed by the server.
- eximius 8y ago
  > Secondly, why would the JWT continue to grow? I replied to your other comment more completely, but thought this part was worth answering as well. If you are using JWTs for stateless authentication/authorization, you need to include the identity (which doesn't grow) AND the list of authorizations (which might grow). And, even if it doesn't grow, JWTs are quite large compared to the HMAC of a random token. HMAC size: 64 bytes, JWT size: several hundreds of bytes, easily a few kb, if we put more than the bare minimum.