"New Device Logged In" shows wrong IP #3995

New Issue

2026-03-07T19:22:54-06:00

GiteaMirror commented

2026-03-07 19:22:54 -06:00

Originally created by @tycho on GitHub (Aug 1, 2019).

The "New Device Logged In" email gave me this:

Date: Thursday, August 1, 2019 at 10:19
IP Address: 127.0.0.1
Device Type: Chrome

My nginx config is setting the X-Real-IP and X-Forwarded-For headers for the reverse proxy. Am I missing some other one that would make it recognize what the real client IP is? Or is bitwarden_rs just ignoring those headers for some reason?

Originally created by @tycho on GitHub (Aug 1, 2019). The "New Device Logged In" email gave me this: ``` Date: Thursday, August 1, 2019 at 10:19 IP Address: 127.0.0.1 Device Type: Chrome ``` My nginx config is setting the `X-Real-IP` and `X-Forwarded-For` headers for the reverse proxy. Am I missing some other one that would make it recognize what the real client IP is? Or is bitwarden_rs just ignoring those headers for some reason?

GiteaMirror closed this issue

2026-03-07 19:22:55 -06:00

GiteaMirror commented

2026-03-07 19:22:55 -06:00

@janost commented on GitHub (Aug 1, 2019):

Are you sure you are properly setting X-Real-IP?

I was able to reproduce the issue without that header, however adding it back fixed the issue.

@janost commented on GitHub (Aug 1, 2019): Are you sure you are properly setting `X-Real-IP`? I was able to reproduce the issue without that header, however adding it back fixed the issue.

GiteaMirror commented

2026-03-07 19:22:55 -06:00

@tycho commented on GitHub (Aug 1, 2019):

I just figured it out. nginx seems to violate the "principle of least astonishment" for me rather frequently.

Here's basically what I had (removed the unimportant stuff to focus on the issue itself):

upstream bitwarden {
        server 127.0.0.1:8378;
        keepalive 16;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        [...]

        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;

        location / {
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_pass http://bitwarden;
        }

        location /notifications/hub {
                proxy_pass http://127.0.0.1:3012;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }

        location /notifications/hub/negotiate {
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_pass http://bitwarden;
                access_log off;
        }
}

The problem was that apparently the proxy_set_headers in the server{} scope don't propagate to child location ... {} scopes. When I do this, it works as intended:

upstream bitwarden {
        server 127.0.0.1:8378;
        keepalive 16;
}
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        [...]


        location / {
                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://bitwarden;
        }

        location /notifications/hub {
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header 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://127.0.0.1:3012;
        }

        location /notifications/hub/negotiate {
                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://bitwarden;
                access_log off;
        }
}

I feel like I should just write a tool that generates my nginx configs at this point. They are uncomfortably verbose and I end up doing a lot of duplication to get things to behave.

@tycho commented on GitHub (Aug 1, 2019): I just figured it out. nginx seems to violate the "principle of least astonishment" for me rather frequently. Here's basically what I had (removed the unimportant stuff to focus on the issue itself): ``` upstream bitwarden { server 127.0.0.1:8378; keepalive 16; } server { listen 443 ssl http2; listen [::]:443 ssl http2; [...] 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; location / { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://bitwarden; } location /notifications/hub { proxy_pass http://127.0.0.1:3012; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } location /notifications/hub/negotiate { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://bitwarden; access_log off; } } ``` The problem was that apparently the `proxy_set_header`s in the `server{}` scope don't propagate to child `location ... {}` scopes. When I do this, it works as intended: ``` upstream bitwarden { server 127.0.0.1:8378; keepalive 16; } server { listen 443 ssl http2; listen [::]:443 ssl http2; [...] location / { 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://bitwarden; } location /notifications/hub { proxy_set_header Upgrade $http_upgrade; proxy_set_header 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://127.0.0.1:3012; } location /notifications/hub/negotiate { 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://bitwarden; access_log off; } } ``` I feel like I should just write a tool that generates my nginx configs at this point. They are uncomfortably verbose and I end up doing a *lot* of duplication to get things to behave.

GiteaMirror referenced this issue

2026-04-20 13:57:53 -05:00

[GH-ISSUE #3995] Latest Bitwarden Android app crashes when trying to add a new login entry #10555

GiteaMirror referenced this issue

2026-04-23 06:16:13 -05:00

[GH-ISSUE #3995] Latest Bitwarden Android app crashes when trying to add a new login entry #14532

GiteaMirror referenced this issue

2026-04-25 20:40:06 -05:00

[GH-ISSUE #3995] Latest Bitwarden Android app crashes when trying to add a new login entry #18516

GiteaMirror referenced this issue

2026-06-17 08:48:05 -05:00

[GH-ISSUE #3995] Latest Bitwarden Android app crashes when trying to add a new login entry #29234