HTTP Digest Auth makes it "impossible" to log out

[tibbe]

Being able to log out is useful in a number of circumstances e.g. if you're using someone else's computer or if you have several account. Using HTTP Digest (or Basic) Auth makes it more or less impossible to log out (short of clearing your browser's stored passwords).

[dcoutts]

I've read that it's possible to do this using a bit of cunning trickery. But it's true, browsers do have rather poor support for standard http authentication which we then have to live with or work around.

I think it's worth investigating these tricks. I know that trac uses (or can use) this approach. I'd really rather not force ordinary automatic clients to use a non-standard auth mechanism just because of browser UI issues. Allowing multiple (so simple clients can use standard mechanisms) would be ok but it's not desirable to duplicate things if we don't have to.

[gbaz]

lmao, ugh https://stackoverflow.com/a/43990171/371753

(i mean we may want to try this anyway)

[gbaz]

Alternately, we could just take the hint and lean towards having a more modern auth system.

[gbaz]

You can now logout by clicking on the "account management" link in the "user accounts" page, and then there's a "logout" button in the far right of the topbar. This is a rather awkward process, but it exists, at least...

[yutotakano]

I think the "Logout" functionality isn't working (at least on macOS Edge and Windows Edge browsers) -- clicking on the "Logout" button from the account management page still keeps me logged in. I don't think the "return 401 and the browser will reset auth" is a working strategy anymore.

I've also tried visiting in an incognito window, where I've found that I'm still (!) logged in -- I presume HTTP Digest Auth persists in the browser even into incognito windows, which makes switching accounts very difficult. This all seems to point towards Hackage needing a better auth system.

Perhaps I can look into building in a slightly more modern auth that uses either client-side JWTs or server-side sessions tokens. I'd just like clarification on what the following meant:

I'd really rather not force ordinary automatic clients to use a non-standard auth mechanism just because of browser UI issues.

Was this for e.g. cabal upload and scripts that interface with the Hackage API? I know that Authentication Tokens can be used nowadays for programmatic use cases, perhaps we can even make that the default option for cabal upload. That frees us for Web/UI authentication to use whatever modern auth protocol we want.

[gbaz]

Are you sure this isn't just an edge issue? I just tested both logout and incognito on chrome and firefox and they continue to work as they have.

[yutotakano]

Are you sure this isn't just an edge issue? I just tested both logout and incognito on chrome and firefox and they continue to work as they have.

Hmmm, interesting -- I was unable to log out on macOS Safari as well. Although for Safari, incognito windows prompted me for a fresh login.

[gbaz]

Actually, tested firefox more carefully, and private works but logout does not. Both work on chrome. I agree there's no reliable way to enforce logout across browsers. I don't think that suffices to force the switch to a different auth mechanism, given that with the exception of edge, private mode works -- and sharing auth between private and nonprivate is actually a clear security problem in edge.

[phadej]

Just a comment: basic auth is great authentication mechanism for non-browser workflows (e.g. cabal upload), so I don't think it should be ever removed from API-ish endpoints.

What the website uses, can be some additional auth.

So please, if you do anything, please don't switch, but add another option.

That said, is having a session cookie based authentication that hard?

[yutotakano]

given that with the exception of edge, private mode works

I'm starting to think it's something to do with.... my browser profile? I can't pin point it down and I have zero clue why, but my incognito session is definitely reusing the same Digest auth, but "only for my main Edge browser profile". My Mac and Windows share this common denominator. I tried making a new Edge profile, and there I was able to both log out (!) and get a fresh prompt in incognito...

Apologies everyone involved, this might just be something extremely weird about my browser profile... Rather creepy, I've to say, but it's not Hackage at issue. I don't see a compelling reason any more to switch auth either, if incognito works for everyone else.

Logging out is definitely something I'd love to see eventually implemented properly rather than the existing workaround-y approach (to return 401), and session cookie auth does sound like the direction forward. I might try at some point, but it's not as pressing to me any more.

@phadej: it shouldn't be that difficult to keep both types of auth when it comes to adding it, I agree. However I do wonder about limited adoption of API tokens if we won't ever remove the (comparatively) insecure alternative. Personally I'd love to see something like GitHub's strategy, where they previously used username:password@repo.git for access, gradually deprecated it over several years, and currently only allowing token@repo.git (or SSH) for cloning repos.

[phadej]

I'd say that at GitHub tokens are really forced to exist because of 2FA. I'd love to have 2FA on Hackage, and e.g. tokens restricted only to uploads / revisions making (or best, configurable - even per package) to not undermine additional security added by 2FA.

But I'm also thinking realistically. I don't see 2FA added to Hackage (there is an issue) any time soon, not really before something bad happens.

Yet, OTOH, adding 2FA does indeed solve this issue (indirectly: by removing/adding alternative to http digest auth - as it's 2FA incompatible).