Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DUO redirection after 2FA does not redirect to the subpath with 1.32.0 #4858

Closed
kilaketia opened this issue Aug 14, 2024 · 1 comment · Fixed by #4862
Closed

DUO redirection after 2FA does not redirect to the subpath with 1.32.0 #4858

kilaketia opened this issue Aug 14, 2024 · 1 comment · Fixed by #4862
Labels
bug Something isn't working

Comments

@kilaketia
Copy link

Subject of the issue

After 2FA verification is done, DUO redirect us to https://fqdn/duo-redirect-connector.html instead of https://fqdn/subpath/duo-redirect-connector.html.

Deployment environment

  • vaultwarden version: 1.32.0

  • Install method: Docker

  • Clients used: web vault

  • Reverse proxy and version: NGINX 1.22.1-9

  • MySQL/MariaDB or PostgreSQL version: MariaDB

  • Other relevant details:

Steps to reproduce

Try to login with DUO 2FA, with Vaultwarden accessible from a sub path only, using the old interface or the universal prompt of DUO.

Expected behaviour

User should be redirected to https://fqdn/subpath/duo-redirect-connector.html after 2FA verification with DUO.

Actual behaviour

User is redirected to https://fqdn/duo-redirect-connector.html and receive a 404 error.

Troubleshooting data

Vaultwarden is configured with domain as "https://fqdn/vault/".

NGINX configuration :

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8080;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
        listen 443 ssl http2;
        server_name vault.mydomain.com;
        ssl_certificate /etc/ssl/private/cert.pem;
        ssl_certificate_key /etc/ssl/private/key.pem;
        client_max_body_size 128M;

        access_log /var/log/nginx/vault.access.log;
        error_log /var/log/nginx/vault.error.log warn;
        add_header X-Robots-Tag "none";

         location /vault/ {
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
        	proxy_pass http://vaultwarden-default;
        }

        location /vault/admin {
                allow 192.168.1.0/24;
                deny all;

                proxy_http_version 1.1;
                proxy_set_header "Connection" "";
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_pass http://vaultwarden-default;
        }

        proxy_connect_timeout       777;
        proxy_send_timeout          777;
        proxy_read_timeout          777;
        send_timeout                777;
}

server {
        listen 80;
        server_name vault.mydomain.com;
        return 301 https://$host$request_uri;
}

Temporary fix :

 location / {
                rewrite ^/duo-redirect-connector.html$ /vault/duo-redirect-connector.html?$args permanent;
}
@BlackDex BlackDex added the bug Something isn't working label Aug 14, 2024
@GeorgeCastanza
Copy link

GeorgeCastanza commented Aug 14, 2024

I suspect this is my issue too. When I login, the cloudflare tunnel is not redirecting properly (I guess??) and it's forwarding to my router page, not my vw instance.

Edit: login via email code does work.

BlackDex added a commit to BlackDex/vaultwarden that referenced this issue Aug 15, 2024
The URL crate treats `https://domain.tld/path` differently then
`https://domain.tld/path/` the latter will make sure a `.join()` will
append the given path instead of using the base as a relative path.

Fixes dani-garcia#4858
dfunkt pushed a commit to dfunkt/vaultwarden that referenced this issue Aug 15, 2024
The URL crate treats `https://domain.tld/path` differently then
`https://domain.tld/path/` the latter will make sure a `.join()` will
append the given path instead of using the base as a relative path.

Fixes dani-garcia#4858
dani-garcia pushed a commit that referenced this issue Aug 15, 2024
The URL crate treats `https://domain.tld/path` differently then
`https://domain.tld/path/` the latter will make sure a `.join()` will
append the given path instead of using the base as a relative path.

Fixes #4858
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants