4 ms·

Without cookies - and knowing that HTTP is a stateless protocol - how do you suggest we implement a solution that allows me to connect on my bank to view my acc

by IMTDb 4y ago

Without cookies - and knowing that HTTP is a stateless protocol - how do you suggest we implement a solution that allows me to connect on my bank to view my account balance and make a wire transfer from the comfort of my home ?

int_19h 4y ago
The way we did that kind of thing before cookies was by encoding the state in the URL (for GET requests) or hidden fields (for POST). Higher-level Web frameworks at the time would often abstract this away from the app code while allowing the app to be deployed in either mode. Here's an example for ASP.NET: https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.sessionstatesection.cookieless https://docs.microsoft.com/en-us/dotnet/api/system.web.confi...
- 418tpot 4y ago
  If you encode auth token in the URL then a shared URL accidental or otherwise means being authenticated. There is a lot of existing infrastructure that assumes the URL is public knowledge while cookies are not. If you do this through hidden forms then page navigation can no longer be done through hyperlinks and must now all be form submissions, which means a malfunctioning back button and logout when refreshing or opening a link in a new tab. Please do not do this. First party cookies are very useful and it's bad enough that people keep trying to replace them with javascript+localstorage despite the decades of security best practices that have been built into them. I do agree that we can do away with third party cookies however.
  - int_19h 4y ago
    FWIW I'm not suggesting that people do any of this today. But it is how it was actually done - it wasn't the case that advanced web apps that required per-client state management weren't possible at all without cookies.
    - deepstack 4y ago
      exactly! web developer in the late 90's did that and worked fine. Yeah it is a bit more pain to use, however it keeps web stateless which was a what it suppose to be. If you want to make your fancy desktop stateful programs do it with something that is not document base like html.
      - int_19h 4y ago
        It didn't keep the web stateless, though. It implemented state on top of what we had at the time, with certain flaws that others have already pointed out in this thread.
- nl 4y ago
  I worked on framerworks like this. Heck, I built a (horrible, internal only) one once. The issue with this was that it broke direct linking to pages, or created such ugly and long URLs that they were weren't "sharing" friendly. It was horrible, and cookies were (and remain) a much better solution.
pabs3 4y ago
You could do that using TLS client certificates, but they have terrible UX that browser vendors are only making worse over time. There are also other auth mechanisms natively supported by browsers, like HTTP Basic Auth that can be used.
thehappypm 4y ago
Basic authentication ?
- deepstack 4y ago
  that is fine. It is how user suppose to login to an authenticated area.

by IMTDb 4y ago

int_19h 4y ago

The way we did that kind of thing before cookies was by encoding the state in the URL (for GET requests) or hidden fields (for POST). Higher-level Web frameworks at the time would often abstract this away from the app code while allowing the app to be deployed in either mode. Here's an example for ASP.NET: https://docs.microsoft.com/en-us/dotnet/api/system.web.configuration.sessionstatesection.cookieless https://docs.microsoft.com/en-us/dotnet/api/system.web.confi...

418tpot 4y ago
If you encode auth token in the URL then a shared URL accidental or otherwise means being authenticated. There is a lot of existing infrastructure that assumes the URL is public knowledge while cookies are not. If you do this through hidden forms then page navigation can no longer be done through hyperlinks and must now all be form submissions, which means a malfunctioning back button and logout when refreshing or opening a link in a new tab. Please do not do this. First party cookies are very useful and it's bad enough that people keep trying to replace them with javascript+localstorage despite the decades of security best practices that have been built into them. I do agree that we can do away with third party cookies however.
- int_19h 4y ago
  FWIW I'm not suggesting that people do any of this today. But it is how it was actually done - it wasn't the case that advanced web apps that required per-client state management weren't possible at all without cookies.
  - deepstack 4y ago
    exactly! web developer in the late 90's did that and worked fine. Yeah it is a bit more pain to use, however it keeps web stateless which was a what it suppose to be. If you want to make your fancy desktop stateful programs do it with something that is not document base like html.
    - int_19h 4y ago
      It didn't keep the web stateless, though. It implemented state on top of what we had at the time, with certain flaws that others have already pointed out in this thread.
nl 4y ago
I worked on framerworks like this. Heck, I built a (horrible, internal only) one once. The issue with this was that it broke direct linking to pages, or created such ugly and long URLs that they were weren't "sharing" friendly. It was horrible, and cookies were (and remain) a much better solution.

pabs3 4y ago

You could do that using TLS client certificates, but they have terrible UX that browser vendors are only making worse over time. There are also other auth mechanisms natively supported by browsers, like HTTP Basic Auth that can be used.

thehappypm 4y ago

Basic authentication ?

deepstack 4y ago
that is fine. It is how user suppose to login to an authenticated area.