|
| ▲ | bvrmn 10 months ago | parent | next [-] |
| > if you store session data on the server, identify the user using the Authorization header. And by what miracle browser would send Authorization header? Who sets it? For which domain it could be set? |
| |
| ▲ | IgorPartola 10 months ago | parent [-] | | Take a look at how basic auth is implemented in browsers today. Now imagine expanding it to (a) provide a much nicer and somewhat customizable UI for entering your credentials and (b) using proper encryption. | | |
| ▲ | bvrmn 10 months ago | parent [-] | | What about redirects from other sites, should Authorization behave like cookies? My point is cookies are ok for auth, and you basically should invent same things with another header. | | |
| ▲ | IgorPartola 10 months ago | parent [-] | | That header was invented for this exact purpose before cookies were invented. It has wide browser support and semantics that make sense. Moreover, the design specifically includes provisions for additional auth mechanisms (basic and digest being the two most widely used). The downside was that the UI for setting that header was ugly. Your comments remind me of the people who didn’t get HTTP verbs and wanted to use POST for everything before rediscovering REST. | | |
| ▲ | bvrmn 10 months ago | parent [-] | | > and semantics that make sense A paradise for CSRF. > Your comments remind me of the people who didn’t get HTTP verbs and wanted to use POST for everything before rediscovering REST. REST is not about HTTP methods if you read the paper. It's curious you have a direct map between HTTP methods and REST verbs as your mental model. |
|
|
|
|
|
| ▲ | baggy_trough 10 months ago | parent | prev [-] |
| How would you use the Authorization header to implement server side session data? |
| |
| ▲ | magicalhippo 10 months ago | parent | next [-] | | Not a web dev. So do I understand it correctly that it's not so much the server side of this that's the issue, after all the Authorization header contains a nice token, but rather how to safely store the token client side without using cookies? | |
| ▲ | seandoe 10 months ago | parent | prev [-] | | I think they mean storing an identifier in local or session storage and then sending it in the header. | | |
| ▲ | bvrmn 10 months ago | parent | next [-] | | Identifier in local storage could be stolen by 3rd party JavaScript. Anybody who wants to use local storage for sensitive information should read why there is a httpOnly cookie attribute. | | |
| ▲ | IgorPartola 10 months ago | parent [-] | | If you are running third party JS on your site they can just make requests to your server now. Once JS is loaded it is running in the context of your domain. No they can’t do it once the user closes the browser but third party JS is XSS in action. And I am not suggesting using local storage for it. I am suggesting adding browser support for standard/generic login UI. Basically think basic auth, just not so basic. | | |
| ▲ | bvrmn 10 months ago | parent [-] | | > Basically think basic auth, just not so basic It's like technobros trying to invent an inferior train with each pod iteration. |
|
| |
| ▲ | baggy_trough 10 months ago | parent | prev [-] | | It doesn't work with basic multi page sites though. | | |
|
|
