4 ms·

Hah, I’m too old. Still remember the time when basic http auth was a big thing, and you read articles like “how to do password authentication “dynamically”… I

by seer 3y ago

Hah, I’m too old. Still remember the time when basic http auth was a big thing, and you read articles like “how to do password authentication “dynamically”… I guess its a good thing that people have gone through hype and now are in search for a smaller more focused tool. I wonder why standard committees don’t seem to be working on a auth solution that doesn’t require code and is more just markup/server config, but with modern things like passkeys and stuff… or maybe I’ve missed something obvious.

dec0dedab0de 3y ago
Every time I have to make an auth page I get mad that basic auth sucks, because it really should be built into the browser. If I had to guess, I would say that the web was supposed to be stateless, and cookies/local storage were tacked on after the fact to give it state, so by the time WebApps became more common than web pages people were already used to custom login pages.
- deaddodo 3y ago
  > because it really should be built into the browser. It is? And I imagine that's why it "sucks" for you, since I think you actually mean it should be built-in to the HTML / Styling of the site. But that would defeat the purpose, to a degree.
  - dec0dedab0de 3y ago
    Sorry, I may have worded that a bit weird. I meant that basic auth sucks, so we can't use it and take advantage of the login built in the browser. Basic auth sucks because it sends the password for every request, and for get requests it shows in the url, and ends up in logs and whatnot. I don't care about styling at all.
    - bawolff 3y ago
      > Basic auth sucks because it sends the password for every request, Normal auth sends a cookie every request. That is really the same. You have to do state somehow. > and for get requests it shows in the url This is not true
      - dec0dedab0de 3y ago
        Normal auth sends a cookie every request. That is really the same. You have to do state somehow. Sending a token and sending a password are not the same thing. And I thought basic auth GET requests looked like this: http://username:password@somesite.com http://username:password@somesite.com, did that change at some point?
        detaro 3y ago
        That never was the case. That's a syntax to put credentials in a URL if you want to share a link containing the credentials, but has nothing to do with what the requests look like. (your browser also doesn't show it in the URL bar if you access a protected website)
        dec0dedab0de 3y ago
        You just blew my mind, thank you for correcting me. I don't know how I've been wrong about this for so long.
      - wizofaus 3y ago
        "sends a cookie every request. That is really the same" Not exactly, as a cookie a) isn't something you can just read and remember easily (noting that Basic Auth uses base64-encoding, but that's a pretty flimsy layer of 'protection') b) is only of any use for a single session in a single context. If I see somebody's password while inspecting logs/network traffic etc. there's a decent chance I'll be able to use that information to help me access any number of resources that user might access, at any time. What I don't get is why there's no proposal yet (that I'm aware of) to have browsers automatically send Authorization headers once a bearer token has been established for a particular domain or URL path.

by seer 3y ago

dec0dedab0de 3y ago

Every time I have to make an auth page I get mad that basic auth sucks, because it really should be built into the browser. If I had to guess, I would say that the web was supposed to be stateless, and cookies/local storage were tacked on after the fact to give it state, so by the time WebApps became more common than web pages people were already used to custom login pages.

deaddodo 3y ago
> because it really should be built into the browser. It is? And I imagine that's why it "sucks" for you, since I think you actually mean it should be built-in to the HTML / Styling of the site. But that would defeat the purpose, to a degree.
- dec0dedab0de 3y ago
  Sorry, I may have worded that a bit weird. I meant that basic auth sucks, so we can't use it and take advantage of the login built in the browser. Basic auth sucks because it sends the password for every request, and for get requests it shows in the url, and ends up in logs and whatnot. I don't care about styling at all.
  - bawolff 3y ago
    > Basic auth sucks because it sends the password for every request, Normal auth sends a cookie every request. That is really the same. You have to do state somehow. > and for get requests it shows in the url This is not true
    - dec0dedab0de 3y ago
      Normal auth sends a cookie every request. That is really the same. You have to do state somehow. Sending a token and sending a password are not the same thing. And I thought basic auth GET requests looked like this: http://username:password@somesite.com http://username:password@somesite.com, did that change at some point?
      - detaro 3y ago
        That never was the case. That's a syntax to put credentials in a URL if you want to share a link containing the credentials, but has nothing to do with what the requests look like. (your browser also doesn't show it in the URL bar if you access a protected website)
        dec0dedab0de 3y ago
        You just blew my mind, thank you for correcting me. I don't know how I've been wrong about this for so long.
    - wizofaus 3y ago
      "sends a cookie every request. That is really the same" Not exactly, as a cookie a) isn't something you can just read and remember easily (noting that Basic Auth uses base64-encoding, but that's a pretty flimsy layer of 'protection') b) is only of any use for a single session in a single context. If I see somebody's password while inspecting logs/network traffic etc. there's a decent chance I'll be able to use that information to help me access any number of resources that user might access, at any time. What I don't get is why there's no proposal yet (that I'm aware of) to have browsers automatically send Authorization headers once a bearer token has been established for a particular domain or URL path.