2

Perhaps this is a somewhat broad question, but I am currently relying on shots in the dark ...

We sometimes provide access to some web URLs (running Apache 2.4) protected by basic password protection. I have never seen it myself, but every now and then I hear from external users that they are immediately seeing a 401 Unauthorized error. While it is true that the server reply is by design a 401 error code, it is also accompanied by a www-authenticate header, and this should trigger a login dialog at the user's end (where they should enter the credentials we gave them). In the cases in question, it is reported that no login dialog appeared. Unfortunately, I never have direct contact with the affected external users that would allow me a deeper analysis.

  • Does there exist a somewhat common browser that does not understand the www-authenticate machanism? CanIUse surprisingly suggests that Sfari and Opera are problematic - however I just made a successfull test with one of them.
  • Do there exist other common obstacles, e.g., firewall policies that rigorously strip the needed http headers?
  • Any other ideas what could be going wrong in these cases, or what I could test?

EDIT: Regarding things that were suggested for consideration:

  • The URLs in question are https: (may I say - of course?)
  • The problems occur with first-time users, i.e., they never get "in" in the first place. (Nevertheless, my understanding would be that a cached wrong password is supposed to trigger the dialog for the user to try again). This also seems to rule out password manager problems
  • I doubt that the affected users have settings in place that make them automatically try their windows credentials or other automatic logins with (to them) foreign internet hosts.
Hagen von Eitzen
  • 816
  • 3
  • 15
  • 41
  • The specifics are fixed, but the general bug class of related issues I found long ago might still apply: bad client UI was always triggered with **unusual entry points**, e.g.: the first 401 response being received by the built-in PDF viewer, the target of an POST form (re-submitted from an old browser tab), a non-canonicalized `https://user@example.com/fileslash/` URL being the result of my link being modified by the recipients MUA. You might make some progress by a) looking at what were the first two requests per IP and b) special-casing empty passwords. – anx Aug 06 '21 at 20:34
  • Does your `realm=` value contain any funny characters, comma being one? Ideally, keep it simple, because parsing *almost* like the RFC ABNF is a common source of bugs ;) – anx Aug 06 '21 at 20:43
  • Chromium will purposefully not support *basic auth* popups if the header is loaded on a sub-resource that does not match origin. You can tell whether someone is accessing your site embedded somewhere by logging *refer(r)er* and *fetch metadata request headers*. – anx Aug 21 '21 at 15:18

1 Answers1

2

A few things to try or consider:

  • Are you serving these pages securely? There is a GPO and Google Workspace setting that only allows basic auth using HTTPS - GPO, Chrome Policy

  • Do the credentials to the URLs change reasonably frequently? It could be possible the user hasn't closed/restarted their browser since their last successful login and subsequently the credential change causing the httpauth cache to be incorrect and cause the issue.

  • There are some auth settings in the Windows Internet Options dialog that apply to Chrome and IE that could cause an attempted automatic login.

Security settings dialog

  • Are there any password managers that can autofil the login dialog?

  • Just did a few quick tests with some online proxies and a HTTP basic auth prompt with mixed results. Some refused to load the page, some presented their own login prompt and some used the built in browser prompt. It suggests that a misconfigured proxy could cause no login prompt to appear.

Crimsonfox
  • 341
  • 1
  • 2
  • 16