It’s the same as with Linux, GIMP, LibreOffice or OnlyOffice. Some people are so used to their routines that they expect everything to work the same and get easily pissed when not.
It’s the same as with Linux, GIMP, LibreOffice or OnlyOffice. Some people are so used to their routines that they expect everything to work the same and get easily pissed when not.
This is false.
Lemmy’s JWTs are forever tokens that do not expire. They do not have any expiration time. Here is the line of code where they disable JWT expiration verification.
Lemmy’s JWTs are sent via a cookie and via a URL parameter. Pop open your browser console and look at it.
There is no way to revoke individual sessions other than changing your password.
If you are using a JWT cookie validation does not matter, you need to have robust JWT validation. Meaning JWTs should have short expiration times (~1hr), should be refreshed regularly, and should be sent in the header.
When I said, “it validates the timestamp” I wasn’t talking about the JWT
expclaim (which you’re correct in pointing out that Lemmy doesn’t use). I was talking about how JWT works: The signature is generated from the concatenation of the content of the message which includes theiat(Issued-at) timestamp. The fact that the timestamp is never updated after the user logs in is neither here nor there… You can’t modify the JWT message (including theiattimestamp) in Lemmy’s cookie without having it fail validation. So what I said is true.The JWTs don’t have an expiration time but the cookie does… It’s set to one year which I believe is the default for
actix-web. I’m surprised that’s not configurable.You actually can invalidate a user’s session by forcibly setting their
validator_timein the database to some date before their last password reset but that’s not really ideal. Lemmy is still new so I can’t really hold it against the devs for not adding a GUI feature to forcibly invalidate a user’s sessions (e.g. in the event their cookie was stolen).I also don’t like this statement of yours:
Cookie validation does matter. It matters a lot! Real-world example: You’re using middleware (or an application firewall, load balancer, or similar) that inserts extra stuff into the cookie that has nothing at all to do with your JWT payload. Stuff like that may require that your application verify (or completely ignore) all sorts of things outside of the JWT that exist within the cookie.
Also, using a short expiration time in an app like Lemmy doesn’t make sense; it would be super user-unfriendly. The user would be asked to re-login basically every time they tried to visit a Lemmy instance if they hadn’t used it in <some time shorter than an hour like you suggested>. Remember: This isn’t for message passing it’s for end user session tracking. It’s an entirely different use case than your typical JWT stuff where one service is talking with another.
In this case Lemmy can definitely do better:
When using JWT inside of a cookie (which was not what JWT was meant for if we’re being honest) there’s really no point to using the
expclaim since the cookie itself has its own expiration time. So I agree with the Lemmy dev’s decision here; it’d just be pointless redundant data being sent with every single request.Now let me rant about a JWT pet peeve of mine: It should not require Base64 encoding! OMFG talk about pointless wastes of resources! There’s only one reason why JWT was defined to require Base64 encoding: So it could be passed through the
Authorizationheader in an HTTP request (because JSON allows characters that HTTP headers do not). Yet JWT’s use case goes far beyond being used in HTTP headers. For example, if you’re passing JWTs over a WebSocket why the fuck would you bother with Base64 encoding? It’s just a pointless extra step (and adds unnecessary bytes)! Anyway…