Server: globalSettings__baseServiceUri__admin is being ignored

[jakubgs]

I'm running 1.31.1 using an Ansible role I've created:
https://github.com/status-im/infra-role-bitwarden
And I'm setting the globalSettings__baseServiceUri__admin value in the env/global.override.env file:
https://github.com/status-im/infra-role-bitwarden/blob/65dbfc2f5280352bfa22e64e91ea92f98a19c906/defaults/main.yml#L64
And yet when I curl the service I get the redirect to the wrong location:

 $ curl -si https://secrets.status.im/admin | grep location             
location: http://localhost/login?returnUrl=%2F

I tried changing docker/global.env but that had no effect as well.

[jakubgs]

Interestingly enough the /api route works just fine:

 $ curl -si https://secrets.status.im/api | grep location 
location: https://secrets.status.im/api/

As does /identity, /attachments, and /notifications. Only /admin has issues redirecting.

[jakubgs]

The configuration is clearly correct:

 /opt/bitwarden/env % sudo grep globalSettings__baseServiceUri__ global.override.env     
globalSettings__baseServiceUri__admin=https://secrets.status.im/admin
globalSettings__baseServiceUri__api=https://secrets.status.im/api
globalSettings__baseServiceUri__identity=https://secrets.status.im/identity
globalSettings__baseServiceUri__internalAdmin=http://admin:5000
globalSettings__baseServiceUri__internalApi=http://api:5000
globalSettings__baseServiceUri__internalIdentity=http://identity:5000
globalSettings__baseServiceUri__internalNotifications=http://notifications:5000
globalSettings__baseServiceUri__internalVault=http://web:5000
globalSettings__baseServiceUri__notifications=https://secrets.status.im/notifications
globalSettings__baseServiceUri__vault=https://secrets.status.im

[jakubgs]

I don't think I can fix this redirect myself because if I try to query /login directly I just get back 404, which makes no sense:

 $ curl -si https://secrets.status.im/login
HTTP/2 404

So even if the redirect was correct it would fail anyway.

[jakubgs]

I tried querying the admin container for /login and it does work:

[email protected]:~ % d exec -it bitwarden-nginx bash
root@481b2eae2fec:/# curl -si admin:5000/login | head -n1
HTTP/1.1 200 OK

But the nginx config you provided in the stub archive does not contain a location block for /login proxying to admin contianer, so I don't get how this is supposed to work.

[jakubgs]

What I also don't get is why /admin/login works in the nginx container, but not through it's proxy:

[email protected]:~ % d exec -it bitwarden-nginx bash
root@481b2eae2fec:/# curl -si admin:5000/admin/login | head -n1
HTTP/1.1 200 OK
root@481b2eae2fec:/# curl -si localhost:5001/admin/login | head -n1
HTTP/1.1 404 Not Found

Even though the location block should clearly make it work:

  location /admin {
    proxy_pass http://admin:5000;
    include /etc/nginx/security-headers-ssl.conf;
    include /etc/nginx/security-headers.conf;
    add_header X-Frame-Options SAMEORIGIN;
  }

NOTE: Yes, I changed the proxy port to 5001, I also removed SSL setup from it because I do another proxy in front of it in my setup that does that for me.

[kspearrin]

Can you navigate to https://secrets.status.im/admin/login directly? Your previous post shows you curling https://secrets.status.im/login, which is not a valid endpoint.

[jakubgs]

Your previous post shows you curling https://secrets.status.im/login, which is not a valid endpoint.

Okay, then why exactly does a request made to /admin try to redirect me to /login?

Besides, as you can see in https://github.com/bitwarden/server/issues/546#issuecomment-522047206 /admin/login doesn't work through proxy either.

[jakubgs]

Hmmm, no, the redirect is correct if using the domain:

 $ curl -si https://secrets.status.im/admin | grep location
location: http://localhost/admin/login?returnUrl=%2Fadmin

Maybe it redirects directly to /login only if you make the request from within the proxy container.

But that's not the issue here, the issue is that globalSettings__baseServiceUri__admin is being ignored.

[hedgehog1029]

I'm also seeing this issue - it's making the admin page completely inaccessible.
I've got the globalSettings__baseServiceUri__admin parameter configured correctly, but instead https://bitwarden.example.com/admin redirects to http://bitwarden_admin:5000/login (which... I think that's the value of Host creeping in there???) Turning the proxy transparent causes it to instead redirect to https://bitwarden.example.com/login, which is Wrong:tm: but at least the domain part is right so i get an empty page rather than an error. Accessing /admin/login directly works except none of the assets load, because they're all looking at / rather than /admin, and also trying to login doesn't work because it tries to use /login again.

(I've replaced my domain with an example domain for this comment, I'm using a real domain)

[kicker334]

ditto on this issue as well. I set the parameter in the globalSettings__baseServiceUri__admin=example.com:8532/admin but when I go to to the address, it removes the port number and just directs to example.com/admin/login?returnUrl=%2Fadmin%2F. If I then type in example.com:8532/admin/login?returnUrl=%2Fadmin%2F it will direct to the appropriate address. I've also set the base uri to have the port number attached as well.

[WhenDaBoostHitU]

I'm having the same issue. I'm experiencing exactly what @kicker334 described in their comment above

[cscharf]

This _may_ be caused here by dotnet core's cookie authentication app path being rooted, "/login", however looking into how that may be causing the issue and what remediation steps there may be; this is not apparently affecting all users as many of our self-hosted users are not experiencing this issue so not sure what other factors are at play here (proxy, host environment, browser, headers released by the browser, security permissions, cookie handling settings, etc.). This setting is only used by our Admin app and Business Portal app (the only 2 aspnet core MVC apps in the lineup).

see: https://github.com/bitwarden/server/blob/master/src/Core/Utilities/ServiceCollectionExtensions.cs#L301
c# services.ConfigureApplicationCookie(options => { options.LoginPath = "/login"; options.LogoutPath = "/"; options.AccessDeniedPath = "/login?accessDenied=true"; options.Cookie.Name = $"Bitwarden_{globalSettings.ProjectName}"; options.Cookie.HttpOnly = true; options.ExpireTimeSpan = TimeSpan.FromDays(2); options.ReturnUrlParameter = "returnUrl"; options.SlidingExpiration = true; });

[hedgehog1029]

this bug is fun! it exists but it gets hidden on the default install by an obscure detail of nginx's proxy_pass implementation - I fixed this on my custom setup after figuring this out.

From the nginx proxy_pass documentaton:

If the proxy_pass directive is specified with a URI, then when a request is passed to the server, the part of a normalized request URI matching the location is replaced by a URI specified in the directive:

location /name/ {
   proxy_pass http://127.0.0.1/remote/;
}

(e.g., /name/hello becomes /remote/hello)

If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI:

   location /some/path/ {
       proxy_pass http://127.0.0.1;
   }

You can see in bitwarden's nginx config template here that the admin component is proxied with proxy_pass http://admin:5000; e.g. "without a URI". This leads to the admin backend receiving the full path: /admin/login, which is what it expects.

The problem that I ran into was caused by me mapping the internet-side /admin to the root of the admin service / - this would be the behavior if the proxy_pass directive had a trailing slash. I fixed it on my end in this commit which causes internet-side /admin to map to service-side /admin.

I think the bug still technically exists in that the globalSettings__baseServiceUri__admin config entry is ignored - it seems that the backend bases its redirects on the current request parameters rather than anything else.

[cscharf]

So, the globalSettings__baseServiceUri__admin setting is not used for auth redirects and therefore isn't being ignored, so it's not an issue on that configuration point, those URLs are used for app-to-app redirection/communication (hitting API endpoints, for example, or redirecting to another app, forming URLs, email template host-injection for links, etc.). I linked to the code used for authentication redirect, which this issue is reported above and the intent was never to use that setting (it uses an app path/absolute path (not a full URI) for that redirect to the login page.

[cscharf]

@jakubgs , do @hedgehog1029's comments/fix above resolve the issue you're experiencing?

[jakubgs]

I do not self-host BitWarden anymore since I couldn't get it to work properly. We use a cloud-hosted version now.

[cscharf]

Closing this issue for now, if this comes back up for anyone please feel free to re-open it if the comments above do not resolve the issue (also closing the draft PR).