Set different entries for the Admin panel

[fxzxmic]

The default Admin Panel is always located at http://<Primary Domain Name>/admin. Is it possible to add functionality to change the /admin path to custom path? Or access the Admin panel directly from another domain name?
In fact, it can be done through nginx's reverse proxy, but it will be more complex. It would be better if bitwarden_rs could provide it natively.

[fxzxmic]

No one agrees?

[dumblob]

I agree, but at the same time I'm convinced this is a low priority issue (because there is a "workaround" which is though very common in web deployment and thus often not even considered a "workaround" but rather a standard practice).

[fxzxmic]

I know, I just want developers to think about this idea in future updates. NGINX really does provide this feature (but it's not perfect), so it might be better to have it provided by Bitwarden_rs itself.

[pepa65]

What difference does it make if it is /admin or /custom-path?? I like the idea of setting up a subdomain for it, but that is something that happens outside bitwarden altogether.

[fxzxmic]

Custom paths can hide entries and do some custom usage. The subdomain is similar.
As for your second point, the web server deployed outside Bitwarden_rs can do, but it's not perfect (for example, you need to manually adapt to replace static file addresses and web page elements, and it's still not perfect after replacement, just to the extent of availability). If Bitwarden_rs itself supports it, it doesn't need any additional configuration.

[pepa65]

I guess serving the Admin page on a different port might do the job for you. But I really think the reverse proxy server can do this seamlessly. (I don't know about nginx, I use caddy.)

[fxzxmic]

Hello, with respect to this discussion, I find that the latest update completely breaks down the only way to achieve the desired effect in this discussion by replacing elements with nginx reverse proxies.
The error came from the admin.js file.

[BlackDex]

You probably provide a custom CSP instead of letting Vaultwarden serve the correct one. I suggest to remove your custom headers and let Vaultwarden provide the correct headers.

[fxzxmic]

This is not the problem you mentioned, you can refer to this issue #3415 specifically.

[fxzxmic]

If my domain name is abc.com and my backend address is https://admin.abc.com/vault, then I think the correct request address should be https://admin.abc.com/vault/config/, not https://admin/config/.

[fxzxmic]

I wanted to bring this feature request back up because with the vaultwarden update, replacing hardcoded addresses in js files via nginx's sub_filter function is becoming increasingly impossible.

In other words, the so-called workaround is becoming increasingly difficult to accomplish. In particular, the introduction of the admin_diagnostics.js file.

vaultwarden/src/static/scripts/admin_diagnostics.js

Line 108 in 3c29f82

const jsonResponse = await fetch(`${BASE_URL}/admin/diagnostics/config`, {

vaultwarden/src/static/scripts/admin_diagnostics.js

Lines 280 to 286 in 3c29f82

	fetchCheckUrl(`${BASE_URL}/api/config`),
	fetchCheckUrl(`${BASE_URL}/webauthn-connector.html`),
	fetchCheckUrl(`${BASE_URL}/admin/does-not-exist`),
	fetchCheckUrl(`${BASE_URL}/admin/diagnostics/http?code=404`),
	fetchCheckUrl(`${BASE_URL}/admin/diagnostics/http?code=400`),
	fetchCheckUrl(`${BASE_URL}/admin/diagnostics/http?code=401`),
	fetchCheckUrl(`${BASE_URL}/admin/diagnostics/http?code=403`),

vaultwarden/src/static/scripts/admin_diagnostics.js

Line 372 in 3c29f82

const isConnected = await fetchWsUrl(`${BASE_URL}/notifications/anonymous-hub?token=admin-diagnostics`).catch(() => false);

You'll find that it's hard to handle these URLs with just a few replacement rules, and you'll basically need to write replacement rules for each URL.

[BlackDex]

Also, i think it doesn't have to be that complex as you say btw.

There are two differences. URL's that start with ${BASE_URL}/admin and URL's that do not.
That is as far as i can see the only difference.
So probably replacing ${BASE_URL}/admin your admin endpoint and then the rest to the non-admin endpoint should be enough.

[fxzxmic]

It's not really complicated, set ${BASE_URL} to a value that can be set via the config file. For addresses that point to the main domain (like ${BASE_URL}/api/config), use another variable.

Also, i think it doesn't have to be that complex as you say btw.

What I actually mean is that it is becoming more and more complex, and there may come a time when it is literally impossible to write replacement rules anymore.
I've been using this software for years, and I'm the one who keeps watching the replacement rules I use get more and more complicated.

[BlackDex]

That means we have to add a special ADMIN_DOMAIN, which we would need to check and verify and make sure we use that at correct locations. In my eyes that makes it more complex, especially if for example an admin domain does not have a sub-path and the normal domain does. And that i haven't even started about the multi-domain support at all. So, no it is not as easy as you say.

I do not see the issue why you just not use these rules, which in theory should work just fine.

  sub_filter '`${BASE_URL}/admin/'  '`https://admin.abc.com/vault/admin/';
  sub_filter '`${BASE_URL}/'  '`https://abc.com/vault/';
  sub_filter_once off;

[fxzxmic]

I'm not running into any issue right now, I'm just seeing an increasingly bloated number of replacement rules that basically need to be added every few updates.

[BlackDex]

Here, this will release you from your burden.

# ----
geo $dollar {
  default "$";
}
# ----
server{
   # ----
    location ~ .*/vw_static/admin.*.js {
      sub_filter_types "text/javascript";
      sub_filter '`${dollar}{BASE_URL}/admin/'  '`https://admin.abc.com/vault/admin/';
      sub_filter '`${dollar}{BASE_URL}/'  '`https://abc.com/vault/';
      sub_filter_once off;
      proxy_pass http://vaultwarden;
    }
   # ----
}