Wrong WWW-Authenticate: Basic ... header with basic auth being disabled

[kulmann]

Describe the bug

The authentication middleware seems to wrongfully add a WWW-Authenticate: Basic ... header in some situations. The code reads like that should only ever exist if basic auth is enabled. But I managed to get some edge cases responses with a 401 and both WWW-Authenticate: Basic ... and WWW-Authenticate: Bearer ... headers.

Steps to reproduce

Just run the following curl agains an ocis instance running on https://host.docker.internal:9200 (or change the URL respectively).

curl 'https://host.docker.internal:9200/ocs/v2.php/apps/notifications/api/v1/notifications?format=json' \
  -H 'Accept: */*' \
  -H 'Cache-Control: no-cache' \
  -H 'Connection: keep-alive' \
  -H 'Pragma: no-cache' \
  -H 'Referer: https://host.docker.internal:9200/files/spaces/personal/admin?fileId=1284d238-aa92-42ce-bdc4-0b0000009157%24some-admin-user-id-0000-000000000000%21some-admin-user-id-0000-000000000000&items-per-page=100&view-mode=resource-table&tiles-size=1' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36' \
  -H 'accept-language: en' \
  -H 'authorization: Bearer eyJhbGciOiJQUzI1NiIsImtpZCI6InByaXZhdGUta2V5IiwidHlwIjoiSldUIn0.eyJhdWQiOiJ3ZWIiLCJleHAiOjE2ODAyNzY0MDQsImlhdCI6MTY4MDI3NjMzNCwiaXNzIjoiaHR0cHM6Ly9ob3N0LmRvY2tlci5pbnRlcm5hbDo5MjAwIiwianRpIjoiel9kYTRXeVNEaVk3TzYyTDR3eGltZ2VlbEkyMTg5NHkiLCJsZy5pIjp7ImRuIjoiQWRtaW4iLCJpZCI6InVpZD1hZG1pbixvdT11c2VycyxvPWxpYnJlZ3JhcGgtaWRtIiwidW4iOiJhZG1pbiJ9LCJsZy5wIjoiaWRlbnRpZmllci1sZGFwIiwibGcudCI6IjEiLCJzY3AiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInN1YiI6InZuMDQ3WURFb0pkYkZIUTdAeDBvOEFqZ2VCOHZhRUs4TTVyRDFuSVIzNTlhVVZLUlhzWThMU1NPQ3pWXzhySndST2lmUVFBbjlQeEJ4Z29tSmxtUE5FUSJ9.I9umYoI3IVoDGQNlXNiwI1YN8WnJPIuSJOMFykQxpzLraPAli6EPquyGzdjaTySeBbzzbU3OFvE0mR8b--3fknWNUV8M0e54e-SS2vt008xPzD97NEKF2j8QyoFO7To6Nrzc3TtpFV4qIo8NOz7CWt4ali2r8ETmlQr0j1bonMgE_twY_wCeS46iaA06EkyXVeCEOL9JBsUEDcBrRhy93ydWDTBcC3UzmeIAh5PAimemwn-bDaw9S9seI3TEBwSgOs5GE_xCgkXcpoCd5RCt7OOlkhN1gNf1n9kt35CDv3BBr5QlRZB9vEeqAbEXQjJkslKuTMZtQ6YIyjEebmp1lzmxD00w3GUBuEpruUJJfC2wDzTAPqqERAaZ91a7jCNSK_vB17Yfv4Vffip4MXCCnAyF_Hz0zyITedNRuw29Mk6frlzgcLCQWZPuSIydxB6bJnv1c-sfiLRGC9gBm1QIsH6Jl0H6ZyUa-c9eK38pG9r2YZflpwaw-N5co0weh_-k00YtYRj0y-fT3FCyU-QgJIO2AuLs5WNQg33nQaeHNFEGyA3YWn2fHoDJHeaWQQo7i02b37i4vmZwYfYNbMkIlETyAXe3X_MdNmBttE7zmX0AerEhvw4FtKDsZEK9o45xc0Qqa5OA2CjVb9tztypsgMjBifRAYogVq8ToIDgSPaI' \
  -H 'ocs-apirequest: true' \
  -H 'sec-ch-ua: "Google Chrome";v="111", "Not(A:Brand";v="8", "Chromium";v="111"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'x-request-id: 2424e1a6-b305-4bfe-b956-12c93bc7e3dc' \
  -H 'x-requested-with: XMLHttpRequest' \
  --compressed \
  --insecure

Since the access token is already expired, ocis returns:

> x-requested-with: XMLHttpRequest
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Www-Authenticate: Bearer realm="host.docker.internal:9200", charset="UTF-8"
< Www-Authenticate: Basic realm="host.docker.internal:9200", charset="UTF-8"

It should just have failed silently with a 401 and < Www-Authenticate: Bearer realm="host.docker.internal:9200", charset="UTF-8". The < Www-Authenticate: Basic realm="host.docker.internal:9200", charset="UTF-8" is wrong and results in the browser showing a basic auth popup. Which is awful user experience. :-(

How is this relevant

The rare edge case that I had was that the notification request was started in between some token renewal related requests. It seems like the internal idp or some middleware invalidates the access token as soon as a new one is requested. That seems to be totally fishy. I suppose this is not an edge case when you have a few thousand users in a system. That's just bad timing / a race condition that we don't want to have.

In the wild this will likely only ever happen with a scheduled notification listing request being badly timed in the middle of token renewal. Still, in production environments this will happen on a not so frequent but regular basis.

[micbar]

I am reading the code. This really happens only if PROXY_ENABLE_BASIC_AUTH is set.

Are you supposing to never return a Www-Authenticate: Basic header even if both authentication methods are avaiilable?

[kulmann]

I am reading the code. This really happens only if PROXY_ENABLE_BASIC_AUTH is set.

Was reading the code as well and was really confused because I understood it the same way as you. But your implication is right, I just now found the env var in my docker compose, enabling basic auth. 😠 😆 Really sorry for the noise. To give you some fun: I was searching in my docker compose file with lower case basic and had case sensitive search enabled... which I usually don't have. Haha 😅

Are you supposing to never return a Www-Authenticate: Basic header even if both authentication methods are avaiilable?

No. Should be fine the way it is.

cc @dschmidt

[dschmidt]

Actually... I would argue that when X-Requested-With is set to XmlHttpRequest, the basic auth www-authenticate header should never be sent

[micbar]

@michaelstingl I would like to fix that.

Cross platform approval needed?

[micbar]

See PR for a possible fix.