4 ms·
an interesting read but one thing I didn't understand, how is one meant to save the plaintext username & password client side (so as to be able to send them wit
by lisp_padawan 18y ago
an interesting read but one thing I didn't understand, how is one meant to save the plaintext username & password client side (so as to be able to send them with each request) without putting them in a cookie or requiring that the user's browser is set to 'remember this password' - anyone got any ideas?
- mtts 18y agoI think the point is not that no session state at all should be stored client side, but that most session state should not be.
- alan 18y agoActually, Peej is a REST fan. He's saying that if there's session state it should be on the client side. There should be none on the server side.
- shutter 18y agoThat's authentication/authorization info; it should/must be stored on the client.
- DougBTX 18y agoIn theory by using a cookie which can be verified by any server, but which can only be generated with the user's password (which is never stored in clear text). There is an article here, http://www.lightbluetouchpaper.org/2008/05/16/hardened-stateless-session-cookies/ http://www.lightbluetouchpaper.org/2008/05/16/hardened-state... but the PDF link seems dead.
- briansmith 18y agoBrowsers have that functionality built in as long as you are using RFC 2617 authentication.
- newt0311 18y agoIn theory. What about in practice?
- eggnet 18y agoIn my experience, the browser doesn't reliably send the username and password with each request so you get a bunch of re-queries. Cookies don't have that problem, they're always sent. At least, that's what I saw on the intranet site I built, switched to authenticating with a login page and cookies instead because of it.