5 ms·
My point is that at some point, you have the control on the server. Of course, you can encrypt the session information in the cookie, and decrypt it on the serv
by ddalex 10y ago
My point is that at some point, you have the control on the server. Of course, you can encrypt the session information in the cookie, and decrypt it on the server end, verify signature, and certify that the user is who they say it is.
This just moves the problem a bit - if you want to log out a user, you can just erase the cookie key from the server side; the cookie will be just random noise at that point.
This approach, of course, assumes that your keys are user specific, possibly generated from the password.
- jessaustin 10y agoYou're right, if every authenticated cookie must also be validated against the DB, there is no point to using authenticated cookies. TFA describes short-lived authenticated cookies, which need not be validated against a DB, used in conjunction with longer-lived DB sessions, which are only validated against the DB when the short-term cookie has expired. Those DB sessions end on logout or reset or whatever.