[GH-ISSUE #1694 ] Domain URL configuration results in 404 #1034

Author

Owner

@BlackDex commented on GitHub (May 16, 2021):

It kinda looks like you manually changed the config.json.
If you did that, it could cause some issues.

If you want to change the domain i suggest to use the -e DOMAIN option or set the correct domain within your docker-compose.yml file, same goes for all other settings and remove the config.json file, stop and start the container again and see what happens.

@BlackDex commented on GitHub (May 16, 2021): It kinda looks like you manually changed the `config.json`. If you did that, it could cause some issues. If you want to change the domain i suggest to use the `-e DOMAIN` option or set the correct domain within your `docker-compose.yml` file, same goes for all other settings and remove the `config.json` file, stop and start the container again and see what happens.

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 17, 2021):

Hi, thx a lot for your Support!

I have deleted the config and set env Variables but it's still the same behavior. When I set the domain env variable it comes up with the same error message.

I have set -e LOG_LEVEL debug but it does not show up in the admin panel.

Do you have some more tipps where to search?
Thx a lot!

@kingofthering commented on GitHub (May 17, 2021): Hi, thx a lot for your Support! I have deleted the config and set env Variables but it's still the same behavior. When I set the domain env variable it comes up with the same error message. I have set -e LOG_LEVEL debug but it does not show up in the admin panel. Do you have some more tipps where to search? Thx a lot!

kerem commented

Author

Owner

@BlackDex commented on GitHub (May 17, 2021):

Does the changed setting not appear in the support string?

All the logs are going to a file in the data folder by default. The file is called vaultwarden.log

Also check the logs of the reverse proxy you use.

@BlackDex commented on GitHub (May 17, 2021): Does the changed setting not appear in the support string? All the logs are going to a file in the data folder by default. The file is called vaultwarden.log Also check the logs of the reverse proxy you use.

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 17, 2021):

I have set all parameters as docker env variables and everything shows up in the support string ... except log_file

"log_file": null,

@kingofthering commented on GitHub (May 17, 2021): I have set all parameters as docker env variables and everything shows up in the support string ... except log_file "log_file": null,

kerem commented

Author

Owner

@BlackDex commented on GitHub (May 17, 2021):

The try to use docker logs vaultwarden or docker logs --since 1440m vaultwarden.
Or to see the current actions: docker logs --follow vaultwarden

@BlackDex commented on GitHub (May 17, 2021): The try to use `docker logs vaultwarden` or `docker logs --since 1440m vaultwarden`. Or to see the current actions: `docker logs --follow vaultwarden`

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 19, 2021):

Thx a lot.
Ok it generates debug log entries in the terminal but unfortunately nothing during startup about the 404 error.
I have migratet all settings to docker env and everything except the domain works.
The proxy is not involved in the problem since I already get the error when I connect directly to the docker container.

Any hint how to debug further?

Thx a lot

@kingofthering commented on GitHub (May 19, 2021): Thx a lot. Ok it generates debug log entries in the terminal but unfortunately nothing during startup about the 404 error. I have migratet all settings to docker env and everything except the domain works. The proxy is not involved in the problem since I already get the error when I connect directly to the docker container. Any hint how to debug further? Thx a lot

kerem commented

Author

Owner

@bokkabonga commented on GitHub (May 25, 2021):

I faced a similiar Problem when deploying vaultwarden (still bitwarden_rs back then) behind an reverse proxy using an apache und CentOS. As far as i understand your configuration correctly you still let vaultwarden handle the ssl encryption, right?
If i remember correctly I had the excact same probmlen as you and solved it by moving the ssl encryption beeing handled by the proxy. So my Setup looked something likes this:

Client <-> Proxy = SSL Encrypted
Proxy <-> Docker = Unencrypted

This should still be fine from a security perspective as far as i know and this is also referrd to in the wiki:

"Note that when you put vaultwarden behind a reverse proxy, the connections between the reverse proxy and vaultwarden are typically assumed to be going through a secure private network, and thus do not need to be encrypted. The examples below assume you are running in this configuration, in which case you should not enable the HTTPS functionality built into vaultwarden (i.e., you should not set the ROCKET_TLS environment variable). If you do, connections will fail since the reverse proxy is using HTTP to connect to vaultwarden, but you're configuring vaultwarden to expect HTTPS."

@bokkabonga commented on GitHub (May 25, 2021): I faced a similiar Problem when deploying vaultwarden (still bitwarden_rs back then) behind an reverse proxy using an apache und CentOS. As far as i understand your configuration correctly you still let vaultwarden handle the ssl encryption, right? If i remember correctly I had the excact same probmlen as you and solved it by moving the ssl encryption beeing handled by the proxy. So my Setup looked something likes this: Client <-> Proxy = SSL Encrypted Proxy <-> Docker = Unencrypted This should still be fine from a security perspective as far as i know and this is also referrd to in the [wiki](https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples): "Note that when you put vaultwarden behind a reverse proxy, the connections between the reverse proxy and vaultwarden are typically assumed to be going through a secure private network, and thus do not need to be encrypted. The examples below assume you are running in this configuration, in which case you should not enable the HTTPS functionality built into vaultwarden (i.e., you should not set the ROCKET_TLS environment variable). If you do, connections will fail since the reverse proxy is using HTTP to connect to vaultwarden, but you're configuring vaultwarden to expect HTTPS."

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 25, 2021):

Hi Bokkabonga,
thx a lot for your reply and that you had the same problem.
I do not have a secure tunnel between the proxy and docker and therefore need the secured connection.

However, I will try to disable ROCKET_TLS and check if the problem is caused by this setting.

Thx a lot

@kingofthering commented on GitHub (May 25, 2021): Hi Bokkabonga, thx a lot for your reply and that you had the same problem. I do not have a secure tunnel between the proxy and docker and therefore need the secured connection. However, I will try to disable ROCKET_TLS and check if the problem is caused by this setting. Thx a lot

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 25, 2021):

I have removed the ROCLKET_TLS Settings and the problem remain: if the domain setting is present, the server responds 404

@kingofthering commented on GitHub (May 25, 2021): I have removed the ROCLKET_TLS Settings and the problem remain: if the domain setting is present, the server responds 404

kerem commented

Author

Owner

@bokkabonga commented on GitHub (May 25, 2021):

Can you show us your Port mapping for the Docker Container? Or did i miss it in your original post?

@bokkabonga commented on GitHub (May 25, 2021): Can you show us your Port mapping for the Docker Container? Or did i miss it in your original post?

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 25, 2021):

I have mapped:
Apache proxy 443 -> Synology 5555
Docker port 5555 -> Vaultwarden 80

@kingofthering commented on GitHub (May 25, 2021): I have mapped: Apache proxy 443 -> Synology 5555 Docker port 5555 -> Vaultwarden 80

kerem commented

Author

Owner

@bokkabonga commented on GitHub (May 25, 2021):

How excactly did you map this in your Docker-Compose? I remember someone facing a similiar problem in the forum who fixed it by changing his port mapping from:

Ports:

5080:443

To:

Ports:

127.0.0.1:5080:443

I´m not sure however if this is a possible solution for you, but might me worth a shot.

@bokkabonga commented on GitHub (May 25, 2021): How excactly did you map this in your Docker-Compose? I remember someone facing a similiar problem in the forum who fixed it by changing his port mapping from: Ports: - 5080:443 To: Ports: - 127.0.0.1:5080:443 I´m not sure however if this is a possible solution for you, but might me worth a shot.

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 25, 2021):

hi,
i have tested to use port 443 of the docker container but it does not respond at all.

thx

@kingofthering commented on GitHub (May 25, 2021): hi, i have tested to use port 443 of the docker container but it does not respond at all. thx

kerem commented

Author

Owner

@bokkabonga commented on GitHub (May 25, 2021):

Ah Sorry if this was misleading. I was rather reffering to adding 127.0.0.1 to the mapping, not changing the Port!

@bokkabonga commented on GitHub (May 25, 2021): Ah Sorry if this was misleading. I was rather reffering to adding 127.0.0.1 to the mapping, not changing the Port!

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 25, 2021):

So this is my docker port mapping, which one do you propose to bind to localhost?
The port inside the container or the docker interface one?

"port_bindings" : [
{
"container_port" : 3012,
"host_port" : 0,
"type" : "tcp"
},
{
"container_port" : 80,
"host_port" : 5555,
"type" : "tcp"
}
],

@kingofthering commented on GitHub (May 25, 2021): So this is my docker port mapping, which one do you propose to bind to localhost? The port inside the container or the docker interface one? "port_bindings" : [ { "container_port" : 3012, "host_port" : 0, "type" : "tcp" }, { "container_port" : 80, "host_port" : 5555, "type" : "tcp" } ],

kerem commented

Author

Owner

@bokkabonga commented on GitHub (May 25, 2021):

If i understand this correctly i would suggest the following:

"port_bindings" : [
{
"container_port" : 3012,
"host_port" : 0,
"type" : "tcp"
},
{
"container_port" : 127.0.0.1:80,
"host_port" : 5555,
"type" : "tcp"
}
],

@bokkabonga commented on GitHub (May 25, 2021): If i understand this correctly i would suggest the following: "port_bindings" : [ { "container_port" : 3012, "host_port" : 0, "type" : "tcp" }, { "container_port" : 127.0.0.1:80, "host_port" : 5555, "type" : "tcp" } ],

kerem commented

Author

Owner

@kingofthering commented on GitHub (May 25, 2021):

thx for the tip ... but it doesnt wortk

how can i troubleshoot this, the debug log doesn't help. what can i do within the container?

@kingofthering commented on GitHub (May 25, 2021): thx for the tip ... but it doesnt wortk how can i troubleshoot this, the debug log doesn't help. what can i do within the container?

kerem commented

Author

Owner

@bokkabonga commented on GitHub (May 25, 2021):

You might want to set the Log_Level env to "debug" or even "trace" to get more detailed logfiles.

@bokkabonga commented on GitHub (May 25, 2021): You might want to set the Log_Level env to "debug" or even "trace" to get more detailed logfiles.

kerem commented

Author

Owner

@JensTimmerman commented on GitHub (Jun 1, 2021):

I'm seeing the same issue,

when I configure my url to be https://example.com/bitwarden/ rocket seems to generate bitwarden/api/xxx routes

however the normal routes should still be in place because I have bitwarden running on http://0.0.0.:8000 and have it behind an nginx proxy that makes it available at https://example.com/bitwarden/

setting the url in the config to https://example.com/ makes bitwarden work, however the admin interface then does not work. So at the moment I have the workaround but this makes the admin interface not work, which I actually need to work...

is there a way to set domain_origin in the config file?

@JensTimmerman commented on GitHub (Jun 1, 2021): I'm seeing the same issue, when I configure my url to be https://example.com/bitwarden/ rocket seems to generate bitwarden/api/xxx routes however the normal routes should still be in place because I have bitwarden running on http://0.0.0.:8000 and have it behind an nginx proxy that makes it available at https://example.com/bitwarden/ setting the url in the config to https://example.com/ makes bitwarden work, however the admin interface then does not work. So at the moment I have the workaround but this makes the admin interface not work, which I actually need to work... is there a way to set domain_origin in the config file?

kerem commented

Author

Owner

@BlackDex commented on GitHub (Jun 1, 2021):

I'm seeing the same issue,

when I configure my url to be https://example.com/bitwarden/ rocket seems to generate bitwarden/api/xxx routes

however the normal routes should still be in place because I have bitwarden running on http://0.0.0.:8000 and have it behind an nginx proxy that makes it available at https://example.com/bitwarden/

setting the url in the config to https://example.com/ makes bitwarden work, however the admin interface then does not work. So at the moment I have the workaround but this makes the admin interface not work, which I actually need to work...

is there a way to set domain_origin in the config file?

You can't mix/match different entry-points. We need the full actual URL for all items to work.
It's either with or without sub-path, not one IP which has it, and the other which doesn't.

We need to full URL because of e-mails which are sent which need that.
So, i suggest to also access the admin by using https://example.com/bitwarden/admin instead of http://0.0.0.0:8000/admin

@BlackDex commented on GitHub (Jun 1, 2021): > I'm seeing the same issue, > > when I configure my url to be https://example.com/bitwarden/ rocket seems to generate bitwarden/api/xxx routes > > however the normal routes should still be in place because I have bitwarden running on http://0.0.0.:8000 and have it behind an nginx proxy that makes it available at https://example.com/bitwarden/ > > setting the url in the config to https://example.com/ makes bitwarden work, however the admin interface then does not work. So at the moment I have the workaround but this makes the admin interface not work, which I actually need to work... > > is there a way to set domain_origin in the config file? You can't mix/match different entry-points. We need the full actual URL for all items to work. It's either with or without sub-path, not one IP which has it, and the other which doesn't. We need to full URL because of e-mails which are sent which need that. So, i suggest to also access the admin by using `https://example.com/bitwarden/admin` instead of `http://0.0.0.0:8000/admin`

kerem commented

Author

Owner

@JensTimmerman commented on GitHub (Jun 1, 2021):

@BlackDex Sure, I understand, that is exactly what I am trying to do, however, it doesn't work.

If I put DOMAIN=https://example.com/bitwarden/ in the environment I see rocket creating the wrong routes:

[2021-06-01 14:04:00.158][routes][INFO] Routes loaded:
[2021-06-01 14:04:00.158][routes][INFO] GET    /bitwarden
[2021-06-01 14:04:00.158][routes][INFO] GET    /bitwarden/<p..> [10]
[2021-06-01 14:04:00.158][routes][INFO] GET    /bitwarden/admin [1]
[2021-06-01 14:04:00.158][routes][INFO] GET    /bitwarden/admin [2]
[2021-06-01 14:04:00.158][routes][INFO] POST   /bitwarden/admin
[2021-06-01 14:04:00.158][routes][INFO] POST   /bitwarden/admin/config
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/config/backup_db
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/config/delete
[2021-06-01 14:04:00.159][routes][INFO] GET    /bitwarden/admin/diagnostics
[2021-06-01 14:04:00.159][routes][INFO] GET    /bitwarden/admin/diagnostics/config
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/invite
[2021-06-01 14:04:00.159][routes][INFO] GET    /bitwarden/admin/logout
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/organizations/<uuid>/delete
[2021-06-01 14:04:00.159][routes][INFO] GET    /bitwarden/admin/organizations/overview
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/test/smtp
[2021-06-01 14:04:00.159][routes][INFO] GET    /bitwarden/admin/users
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/users/<uuid>/deauth
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/users/<uuid>/delete
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/users/<uuid>/disable
[2021-06-01 14:04:00.159][routes][INFO] POST   /bitwarden/admin/users/<uuid>/enable
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/admin/users/<uuid>/remove-2fa
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/admin/users/org_type
[2021-06-01 14:04:00.160][routes][INFO] GET    /bitwarden/admin/users/overview
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/admin/users/update_revision
[2021-06-01 14:04:00.160][routes][INFO] GET    /bitwarden/alive
[2021-06-01 14:04:00.160][routes][INFO] DELETE /bitwarden/api/accounts
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/delete
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/delete-recover
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/delete-recover-token
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/email
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/email-token
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/kdf
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/key
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/keys
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/password
[2021-06-01 14:04:00.160][routes][INFO] POST   /bitwarden/api/accounts/password-hint

it shoudn't put the /bitwarden/ part as part of it routes, since I have a reverse proxy configured to handle request for
https://example.com/bitwarden to http://0.0.0.0:8000/

So that configuration gives a 404

Are you saying I should then configure the reverse proxy to handle request to http://0.0.0.0:8000/bitwarden ?

I don't have a mail server installed, so the urls in the mails are not important to me at the moment.

If I put DOMAIN=https://example.com/ everything seems to work, I can access the admin interface on https://example.com/bitwarden/admin However the css is not loaded, and the api request the admin interfaces tries to make fail. The api requests the rest of voltwarden tries to make work.

@JensTimmerman commented on GitHub (Jun 1, 2021): @BlackDex Sure, I understand, that is exactly what I am trying to do, however, it doesn't work. If I put `DOMAIN=https://example.com/bitwarden/` in the environment I see rocket creating the wrong routes: ``` [2021-06-01 14:04:00.158][routes][INFO] Routes loaded: [2021-06-01 14:04:00.158][routes][INFO] GET /bitwarden [2021-06-01 14:04:00.158][routes][INFO] GET /bitwarden/<p..> [10] [2021-06-01 14:04:00.158][routes][INFO] GET /bitwarden/admin [1] [2021-06-01 14:04:00.158][routes][INFO] GET /bitwarden/admin [2] [2021-06-01 14:04:00.158][routes][INFO] POST /bitwarden/admin [2021-06-01 14:04:00.158][routes][INFO] POST /bitwarden/admin/config [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/config/backup_db [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/config/delete [2021-06-01 14:04:00.159][routes][INFO] GET /bitwarden/admin/diagnostics [2021-06-01 14:04:00.159][routes][INFO] GET /bitwarden/admin/diagnostics/config [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/invite [2021-06-01 14:04:00.159][routes][INFO] GET /bitwarden/admin/logout [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/organizations/<uuid>/delete [2021-06-01 14:04:00.159][routes][INFO] GET /bitwarden/admin/organizations/overview [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/test/smtp [2021-06-01 14:04:00.159][routes][INFO] GET /bitwarden/admin/users [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/users/<uuid>/deauth [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/users/<uuid>/delete [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/users/<uuid>/disable [2021-06-01 14:04:00.159][routes][INFO] POST /bitwarden/admin/users/<uuid>/enable [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/admin/users/<uuid>/remove-2fa [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/admin/users/org_type [2021-06-01 14:04:00.160][routes][INFO] GET /bitwarden/admin/users/overview [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/admin/users/update_revision [2021-06-01 14:04:00.160][routes][INFO] GET /bitwarden/alive [2021-06-01 14:04:00.160][routes][INFO] DELETE /bitwarden/api/accounts [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/delete [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/delete-recover [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/delete-recover-token [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/email [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/email-token [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/kdf [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/key [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/keys [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/password [2021-06-01 14:04:00.160][routes][INFO] POST /bitwarden/api/accounts/password-hint ``` it shoudn't put the `/bitwarden/` part as part of it routes, since I have a reverse proxy configured to handle request for `https://example.com/bitwarden` to `http://0.0.0.0:8000/` So that configuration gives a 404 Are you saying I should then configure the reverse proxy to handle request to `http://0.0.0.0:8000/bitwarden` ? I don't have a mail server installed, so the urls in the mails are not important to me at the moment. If I put `DOMAIN=https://example.com/` everything seems to work, I can access the admin interface on `https://example.com/bitwarden/admin` However the css is not loaded, and the api request the admin interfaces tries to make fail. The api requests the rest of voltwarden tries to make work.

kerem commented