Closed reinob closed 3 years ago
zamuz
commented
3 years ago To add to this, when downloading a file from a Send, the URL for the download (not the share link) is also missing the subpath and therefore the download fails. When clicking the Download button, the URL that the browser attempts to download looks like this (notice the missing subpath):
reneploetz
commented
3 years ago I can only confirm the first issue: The "try it now"-link is indeed broken, but this appears to be hardcoded in the upstream webapp.
But I can create / share / download all sends via browser / (firefox) browser extension and mobile (ios) app with "DOMAIN=https://example.com/bitwarden" using the docker behind an Apache Proxy like below:
RewriteRule ^/bitwarden$ /bitwarden/ [R]
<LocationMatch ^/(?:bitwarden).*>
ProxyPass http://127.0.0.1:8085
RequestHeader set X-Real-IP %{REMOTE_ADDR}s
RequestHeader set X-Forwarded-Proto "https"
RewriteCond %{REQUEST_URI} ^/bitwarden/notifications/hub [NC]
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /bitwarden/notifications/hub(.*) ws://127.0.0.1:8086%{REQUEST_URI} [P,L]
</LocationMatch>My docker-compose configuration looks like this (somewhat simplified for brevity - binding the internal bitwarden http server to port 3011 is still shown, using an external database should not be relevant):
bitwarden:
image: bitwardenrs/server:latest
container_name: bitwarden
ports:
- "127.0.0.1:8085:3011"
- "127.0.0.1:8086:3012"
restart: always
environment:
- DOMAIN=https://example.com/bitwarden
- ROCKET_PORT=3011
- WEBSOCKET_ENABLED=true
volumes:
- data/:/dataIt appears that the urls are relative, which means you probably need to access bitwarden with the slash at the end initially to avoid cutting off part of your path. You could try to test a sub-sub-path like "DOMAIN=https://$HOST/my/vault" to see if that's the case (tough I did not test this at all). It might be more of a problem related to the proxy-server configuration.
BlackDex
commented
3 years ago It works for me. I do not seem to have an issue. using a subpath.
Please check the /admin/diagnostics page to see if everything is configured correctly. If you think all is fine, please generate a support string and paste it here.
zamuz
commented
3 years ago @reneploetz is correct, after applying the reverse proxy configuration pointed out in https://github.com/dani-garcia/bitwarden_rs/issues/1555#issuecomment-810070461, the download works correctly. Many thanks!
reinob
commented
3 years ago Thank you @BlackDex for your message.
From what I can see here it appears that downloading from a generated link should work. This is however also in my case, so this was never an issue.
My issue is that having a subpath the link to "try it now" does not include the subpath. Just hovering on the link should show this, which also shows that this is independent of any reverse proxy configuration. The link is just wrong, while every other link (such as to open an item in the vault) includes the subpath.
@reneploetz above confirmed the "first" issue, which is, for all I know and care, the only issue.
I have nevertheless enabled the admin interface and the diagnostics show everything is OK. I paste here the requested support string.
Hoping that the issue is clear now, I thank you in advance for your support.
{
"_duo_akey": null,
"_enable_duo": false,
"_enable_email_2fa": true,
"_enable_smtp": true,
"_enable_yubico": true,
"_ip_header_enabled": true,
"admin_token": "***",
"allowed_iframe_ancestors": "",
"attachments_folder": "data/attachments",
"authenticator_disable_time_drift": false,
"data_folder": "data",
"database_max_conns": 10,
"database_url": "****/**.*******",
"db_connection_retries": 15,
"disable_2fa_remember": false,
"disable_admin_token": false,
"disable_icon_download": true,
"domain": "*****://******.*****.***/*****",
"domain_origin": "*****://******.*****.***",
"domain_path": "/*****",
"domain_set": true,
"duo_host": null,
"duo_ikey": null,
"duo_skey": null,
"email_attempts_limit": 3,
"email_expiration_time": 600,
"email_token_size": 6,
"enable_db_wal": true,
"extended_logging": true,
"helo_name": null,
"hibp_api_key": null,
"icon_blacklist_non_global_ips": true,
"icon_blacklist_regex": null,
"icon_cache_folder": "data/icon_cache",
"icon_cache_negttl": 259200,
"icon_cache_ttl": 2592000,
"icon_download_timeout": 10,
"invitation_org_name": "Bitwarden_RS",
"invitations_allowed": true,
"ip_header": "X-Real-IP",
"log_file": "/data/bitwarden.log",
"log_level": "Info",
"log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
"org_attachment_limit": null,
"org_creation_users": "",
"password_iterations": 100000,
"reload_templates": false,
"require_device_email": false,
"rsa_key_filename": "data/rsa_key",
"sends_folder": "data/sends",
"show_password_hint": true,
"signups_allowed": false,
"signups_domains_whitelist": "****.***",
"signups_verify": true,
"signups_verify_resend_limit": 6,
"signups_verify_resend_time": 3600,
"smtp_accept_invalid_certs": false,
"smtp_accept_invalid_hostnames": false,
"smtp_auth_mechanism": null,
"smtp_debug": false,
"smtp_explicit_tls": false,
"smtp_from": "*********@****.***",
"smtp_from_name": "Bitwarden_RS",
"smtp_host": "****.****.***",
"smtp_password": "***",
"smtp_port": 587,
"smtp_ssl": true,
"smtp_timeout": 15,
"smtp_username": "*************@******.**",
"templates_folder": "data/templates",
"use_syslog": false,
"user_attachment_limit": null,
"web_vault_enabled": true,
"web_vault_folder": "web-vault/",
"websocket_address": "0.0.0.0",
"websocket_enabled": false,
"websocket_port": 3012,
"yubico_client_id": null,
"yubico_secret_key": null,
"yubico_server": null
}Thx for the detailed report. We will look into it.
reinob
commented
3 years ago Oh, now I realize that, as correctly reflected by your change in title, the issue is only with the "try it now" (as well as the header on that box saying "BITWARDEN SEND").
Besides that box, the "Send" (together with "My Vault", "Tools" and "Settings") works perfectly. So the issue is quite minimal. I could use ublock to remove that box and the issue would be effectively solved :)
BlackDex
commented
3 years ago Also, that try it now link redirects me to the correct page within my own vault, so that does work.
Removing that box is a personal preference i think. And not something we can simply toggle on or off via a setting.
The only thing i see which we maybe should remove or modify the sign up link On the send link page.
Edit: i mean it does work without subpath, not sure with. So that is something also to check.
reneploetz
commented
3 years ago The two links of that box are hardcoded upstream: https://github.com/bitwarden/web/blob/master/src/app/vault/send-info.component.html
We would need to create a pull request in https://github.com/dani-garcia/bw_web_builds and maybe use the working routerLink from navigation: https://github.com/bitwarden/web/blob/master/src/app/layouts/navbar.component.html#L12
I can create a pull request in that repository within the next days unless somebody else wants to do it.
BlackDex
commented
3 years ago Well, i don't know if we want those to be changed actually. They are just links which explains how it works. And we do not have a replacement our selfs.
BlackDex
commented
3 years ago Maybe just removing that whole block would be best indeed.
reinob
commented
3 years ago Well, i don't know if we want those to be changed actually. They are just links which explains how it works. And we do not have a replacement our selfs.
In the box you have four (4) links. "BITWARDEN SEND" (header/title) -> wrong link to own instance (no subpath) "Learn More" -> bitwarden.com (OK, it's just the explanation of how it works) "how it works" -> youtube.com (also OK) "try it now" -> wrong link to own instance (no subpath)
So two of them (Bitwarden/Youtube) can stay like they are. But the first and "try it now" should either be corrected or removed. Otherwise we're just going to have confused users and/or you're going to have more open issues here...
In the top bar (with My Vault, Tools & Settings), the link is OK (with subpath).
I have just upgraded my docker image to 1.20.0 (:latest), and noticed the new "Bitwarden Send" box shown on the upper right corner.
If I click on "try it now" it goes to https://$HOST/#/sends, instead of https://$HOST/**vault/**#/sends, which is what I would expect because I have set DOMAIN=https://$HOST/**vault**
Note that if I correct the URL manually it goes to the right page (I see the "Create New Send" button, etc.) Note that I have not tested further, since I still have to learn about this new feature.
PS: I have another BitwardenRS instance with no sub-path and there it works like a charm! :)