`/control/profile` endpoint returns 401 unauthorized when web ui password/auth is removed/disabled after upgrading from v0.107.64 to v0.107.65

[vincejv]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to report a bug and not ask a question or ask for help

• I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, AMD64 (aka x86_64)

Installation

Docker

Setup

On one machine

AdGuard Home version

v0.107.65

Action

AdguardHome.yaml (password is removed by setting users to [])

http:
  pprof:
    port: 6060
    enabled: false
  address: 0.0.0.0:3020
  session_ttl: 720h
users: []
auth_attempts: 5
block_auth_min: 15
http_proxy: ""
language: en
theme: dark

curl 'https://adguard.DOMAIN.TLD:3020/control/profile' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-US,en;q=0.9' \
  -H 'cache-control: no-cache' \
  -H 'pragma: no-cache' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'sec-gpc: 1'

Expected result

Return HTTP 200 with correct result

Actual result

Returns 401 unauthorized despite web ui password is disabled

Additional information and/or screenshots

The error also reflects on the web interface

[vincejv]

Bug is likely caused by commit: bd3774e introduced by @schzhn

[ainar-g]

Seems like this behaviour has been barely documented, and we've assumed that users: [] can only occur in GLINet compatibility mode, which isn't the case.

@schzhn, we need to process that explicitly and:

1. Print a warning in the log on startup if no users have been defined.
2. Support that in the /profile API and make sure it's properly documented in the code.
3. Document this on the Wiki.

In a future version we'll probably add an explicit setting to disable web auth. Something like:

web:
    auth:
        type: none

[vincejv]

Thanks for acknowledging, since this feature is "undocumented", for now I will switch to the "suggested" workaround by using Basic Auth in the Authentication header for SSO as mentioned here

• Support for Auth proxy #1737
• Let us totally disable connection form #4426

[vincejv]

switch to the "suggested" workaround by using Basic Auth in the Authentication header

actually the issue is much worse now by switching to basic auth... these two end points are now returning 401 after switching

• /control/profile
• /control/tls/status likely a regression by 86de4e7 ?? (not sure) same committer

Raised a separate issue for this, as it seems to be a completely different issue: #7987