3 ms·
One approach that doesn't rely on cookies is HTTP Basic Authentication. The first request to a protected page will produce an authentication prompt[0]. Subsequ
by antsar 8y ago
One approach that doesn't rely on cookies is HTTP Basic Authentication.
The first request to a protected page will produce an authentication prompt[0]. Subsequent requests to the same site will automatically send the same set of credentials (in every browser I'm familiar with. This part of the spec seems to be optional [1]).
Using HTTP Basic Authentication, the server can track the user across different pages. All other state can be maintained on the server side, keyed to the user.
[0] https://i.stack.imgur.com/QnUZW.png https://i.stack.imgur.com/QnUZW.png
[1] https://tools.ietf.org/html/rfc7617#section-2.2 https://tools.ietf.org/html/rfc7617#section-2.2
- eli 8y agoWhy is this better than a session cookie? Basic auth is a pretty wonky user experience. Hard to customize the prompt and "logout" is awkward.
- antsar 8y agoI didn't say it's better :) Just an alternative. One way to handle logout (without closing the browser) is to have a logout link with a destination of "https://bad_username:bad_password@example.com" https://bad_username:bad_password@example.com". I believe this causes the browser to forget the original (valid) credentials and attempt authentication with the invalid credentials. This will fail, and produce a new login prompt. Then you have to close the prompt, and close the subsequent "401" page. So yeah, it is awkward.
- eli 8y agoFair enough. I think modern browsers warn on links with username/password. The UX for basic auth is so bad it is not really a usable feature
- bogomipz 8y agoSure the base64 encoded authorization credentials in the header are the unique identifier in this case. I guess I don't view this so much as an alternative to cookies for general internet browsing much as I do adding a thin layer of security for resources on things like corporate LANs.