mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-05-23 08:32:45 -05:00
[GH-ISSUE #275] Forced signed out #8958
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @quthla on GitHub (Dec 2, 2018).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/275
I am using bitwarden_rs for some days now but I noticed I am signed out frequently. It happened on the mobile but but also the browser extension. I need to login again then.
This never happened using the official implementation. Is there any reason you could think of causing this?
I run bitwarden_rs on my server on port 444 because it's not yet possible to reverse proxy it to a directory. The container was not restarted.
@dani-garcia commented on GitHub (Dec 2, 2018):
Interesting, I only use the web vault, so I haven't noticed this. The authentication tokens are set to expire in two hours, but we also send a refresh token that doesn't expire and would allow the clients to get another authentication token without asking for the password. For contrast, the official vault sends tokens that expire after an hour, so it should work the same.
Do you have two factor authentication enabled? Also, can you check the logs for any message when it asks to log in again?
@pew commented on GitHub (Dec 2, 2018):
I have this issue as well and I think it's related to this issue here. I haven't had the chance to play around with this error code rewriting yet, I also don't think it's the best solution.
@quthla commented on GitHub (Dec 2, 2018):
I don't use 2FA and there's nothing unusual in the logs. Unfortunately logs are not timestamped or else I could look for requests around a particular time.
But the server should never be not available I think.
@quthla commented on GitHub (Dec 5, 2018):
Logged in few hours ago on the ios app, now logged out again :/
There's actually something in the log now. Will post later
@pew commented on GitHub (Dec 5, 2018):
I need to manually log in 80% of the time now, I also don't expect my server to be down but maybe some packet goes missing or (since we're both using Docker container) because the websockets are not working (yet) in the final/latest container release? See #266
@mprasil commented on GitHub (Dec 5, 2018):
Are you using iOS or Android? I've noticed the forced logout once, but unfortunately wasn't able to troubleshoot it just there. But generally speaking bar that one instance it never happened to me on Android. (I still do have to enter the password, but that's because I don't want to store the master password on device)
@pew commented on GitHub (Dec 5, 2018):
@mprasil I'm on iOS 12.1/bitwarden 1.20.0
@quthla commented on GitHub (Dec 5, 2018):
I'm on ios too but it also happened once with the Firefox extension. There's something in the log saying not implemented. Maybe that's the cause
Will post it later
@quthla commented on GitHub (Dec 6, 2018):
@mprasil
This is what I found in the logs.
@dani-garcia commented on GitHub (Dec 6, 2018):
I updated the beta branch with some changes to implement that method and return a similar result to the official server. I'd appreciate if you tested it to see if that solves the issue.
(If you are using the docker hub image, you'll have to wait for @mprasil to trigger the build)
@mprasil commented on GitHub (Dec 6, 2018):
I've now triggered the build, will take about an hour.
I've also experienced some logouts in the mobile app today and that was also the only error message I could see. I start to think that it is some client change, that is slowly rolled out, so I'm only hitting the issue now as my app was updated. Perhaps it was earlier on iPhones?
@dani-garcia, I see there was schema change between master and this beta branch, but it seems to be simple enough that switching between versions should be OK right?
@dani-garcia commented on GitHub (Dec 6, 2018):
It's just a column for the new attachment keys, as long as you don't upload an attachment in the beta version (or convert an old attachment to the new format) it should be fine to move between the two of them. If you do that, then they won't be able to be read from the old version anymore.
Anyway, according to https://rocket.rs/v0.4/news/2018-11-30-version-0.4-rc-2/ the final version of rocket should have been released yesterday, so once it's done -and it'll probably be soon-, this branch is going to be merged in without any major changes, so it can be considered pretty stable.
Still, I would heavily recommend to do a database backup when updating versions just in case.
@quthla commented on GitHub (Dec 6, 2018):
Could you maybe timestamp the logs? Should be easier then to track down issues
@mprasil commented on GitHub (Dec 6, 2018):
@quthla how do you check the logs? If it's via
docker logs, you can use-tto show timestamp.@dani-garcia commented on GitHub (Dec 6, 2018):
I made another change to the beta version, switching to another logging system. Now there are timestamps and log file and syslog support. So you can use that too.
@mprasil commented on GitHub (Dec 6, 2018):
I've triggered another build with latest changes.
Just one note on the extended logging, can we set it to false as default? When users run the server via docker, docker provides its own timestamps. When you run it via some init system like systemd, it also provides its own timestamps.
@dani-garcia commented on GitHub (Dec 6, 2018):
I feel like it would be a better idea to have it enabled by default, and to explicitly change it in the dockerfile / systemd config file.
Basically, set
ENV EXTENDED_LOGGING=falsein the dockerfiles, and configure the systemd service in the same way (which would only be done once). That way everyone gets the best option posible with the least amount of work. What do you think?@mprasil commented on GitHub (Dec 6, 2018):
I'd say if the logs go to stdout, they are either not preserved or they are preserved with timestamp. So maybe we could do extended logs automatically when logging to file is set.
Having that said many servers do log with timestamp just because it was common in the past that the logs were redirected to a file from stdout or whatever was collecting them just stored the lines, so it does look stupid now having the time info twice, but it's just few bytes extra and better to have that info twice than to miss it once. 😄
The only drawback is that we're probably breaking the fail2ban setup some users might have. But I guess that's okay as it will be part of release notes or something.
@mprasil commented on GitHub (Dec 6, 2018):
I'm not really using attachments, so I went ahead and tested the latest beta version. So far all looks OK, no forced log out yet. But that's probably too early to judge. Functionally I didn't spot any major breakage.
@TMHBOFH commented on GitHub (Dec 7, 2018):
Hi,
i test beta release and get with the android app the following error messages.
[2018-12-07][06:52:32][rocket::rocket][INFO] POST /api/accounts/prelogin application/json; charset=utf-8:
[2018-12-07][06:52:32][][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2018-12-07][06:52:32][][INFO] Outcome: Success
[2018-12-07][06:52:32][][INFO] Response succeeded.
[2018-12-07][06:52:32][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded:
[2018-12-07][06:52:32][][INFO] Matched: POST /identity/connect/token (login)
[2018-12-07][06:52:32][bitwarden_rs::api::identity][ERROR] device_identifier cannot be blank
[2018-12-07][06:52:32][][INFO] Outcome: Success
[2018-12-07][06:52:32][][INFO] Response succeeded.
How can i help to find the problem.
@mprasil commented on GitHub (Dec 7, 2018):
FYI: I've renamed the image to
mprasil/bitwarden:betaas there are much more changes than just rocket update. The build is now running.@dani-garcia commented on GitHub (Dec 7, 2018):
@TMHBOFH I made the device_identifier optional in the latest commit just now. It should work fine now.
@quthla commented on GitHub (Dec 7, 2018):
@dani-garcia Upgraded to beta. Uploading / viewing attachments in browser working. I can see the attachment from the iOS app but can neither download nor upload attachments.
There's not even a request logged when trying to download attachments from the iOS app like from the browser.
Uploading from the Android app works, but attachment can not be downloaded after. Says my device wouldn't be able to open the file type (.txt). So maybe this is an issue with the iOS app.
@dani-garcia commented on GitHub (Dec 7, 2018):
For attachments, you probably need to set the
DOMAINenv variable to your server domain or IP and port. Otherwise downloads might not work.I just made some small changes that should be unrelated, but with this last commit and setting the env variable, both upload and download work in browser and ios.
@quthla commented on GitHub (Dec 7, 2018):
Just added
DOMAIN, started container up, was logged out everywhere again. Are the access tokens stored in memory only or is it because I setDOMAINnow?@dani-garcia commented on GitHub (Dec 7, 2018):
The jwt tokens have the domain in them, so when changing it they become invalid. If you log out and log in again it should work.
The No access token provided error after the clear-token is fixed in the latest commit, but you'll have to wait until @mprasil builds a new image.
@mprasil commented on GitHub (Dec 7, 2018):
The image is building. Don't forget to use
mprasil/bitwarden:betaonce the build is done. (about an hour from now)@i-ghost commented on GitHub (Dec 8, 2018):
I'm getting the "No access token provided" error as above on a new install, trying to log in to a newly registered admin account. I'm immediately logged out when I sign in. Using the latest
betatag doesn't seem to fix this.@dani-garcia commented on GitHub (Dec 8, 2018):
Can you provide logs? Also, what devices are you using to connect?
@i-ghost commented on GitHub (Dec 8, 2018):
Of course, here are the logs.
The setup is reverse proxied by nginx according to the example provided in PROXY.md.
I have tried from Chrome desktop, and using the official BitWarden app on iOS.
Update: Ok - so it turns out it was a bad nginx site config - my generic shared config full of
proxy_directives wasn't playing well with BitWarden - excluding it seems to have resolved this. After some further testing, it turns out that settingproxy_set_header Authorization <value>;will cause issues, leaving that out lets BitWarden function normally.@quthla commented on GitHub (Dec 9, 2018):
Once again logged out on iOS unfortunately.
@TMHBOFH commented on GitHub (Dec 9, 2018):
@dani-garcia
thanks for your fast help.
Now i get no error messages in server logs, but unfortunately the app crash after i enter the 2fa token(without any messages).
If i disable the 2fa it works fine.
Thanks for youre help
[2018-12-09][10:36:04][rocket::rocket][INFO] POST /api/accounts/prelogin application/json; charset=utf-8:
[2018-12-09][10:36:04][][INFO] Matched: POST /api/accounts/prelogin (prelogin)
[2018-12-09][10:36:04][][INFO] Outcome: Success
[2018-12-09][10:36:04][][INFO] Response succeeded.
[2018-12-09][10:36:05][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded:
[2018-12-09][10:36:05][][INFO] Matched: POST /identity/connect/token (login)
[2018-12-09][10:36:05][][INFO] Outcome: Success
[2018-12-09][10:36:05][][INFO] Response succeeded.
[2018-12-09][10:36:20][rocket::rocket][INFO] POST /identity/connect/token application/x-www-form-urlencoded:
[2018-12-09][10:36:20][][INFO] Matched: POST /identity/connect/token (login)
[2018-12-09][10:36:20][][INFO] Outcome: Success
[2018-12-09][10:36:20][_][INFO] Response succeeded.
@i-ghost commented on GitHub (Dec 9, 2018):
@TMHBOFH For me, the app only crashes the first time I enter 2FA. Entering it after the crash lets the app function normally.
Unfortunately I am also experiencing the sign out issue on the iOS app. Here are logs of when I tried opening the app, noticed I was signed out, then I signed in again:
Note that this was using the
latesttag, notbeta. I suppose I should trybetaagain and report back.@dani-garcia commented on GitHub (Dec 9, 2018):
@quthla That
Failed to add device to useris strange, I've added some more logging to the latest beta commit, hopefully that will give us more info.@TMHBOFH The crashes happen to me too, on the latest ios app, I'll have to investigate more, though I'm not sure how it's happening.
@i-ghost The issues with the
tokenandclear-tokenendpoints are fixed in the beta, but you are having the same issue as @quthla, so i'd like to now what your results would be running the latest beta.@mprasil Can you trigger a new build, please?
@mprasil commented on GitHub (Dec 9, 2018):
Build triggered, give it about an hour.
A longer term update running latest beta from my side is, that logout issue didn't happen again after switching to beta couple days ago. (on Android)
@i-ghost commented on GitHub (Dec 10, 2018):
Seems promising. Using the
betatag, I haven't used the app in over 12 hours but I've just tried it now and was logged in normally as expected - no forced signing out.@i-ghost commented on GitHub (Dec 11, 2018):
Ok, using the
betatag has definitely resolved the issue with being signed out, at least for me. The 2FA issue (iOS client crash) still persists, but I suspect that's an issue with the app itself. Disabling 2FA on my account works and lets me log in as normal. Not ideal, but it works.@quthla commented on GitHub (Dec 12, 2018):
Ok so after more than 2 days it happened again and now we know what's going on.
@dani-garcia commented on GitHub (Dec 12, 2018):
It's a bit strange, why are there two login requests happening at the same time? It makes sense that the database is locked then, as there would be two connections trying to write to the same place at the same time.
I guess we could retry when there is an error in that case, we already do something similar for attachments, I think.
@quthla commented on GitHub (Dec 12, 2018):
Was asking myself the same question. Guess there's some bug in the client. I just started the app as usual.
@dani-garcia commented on GitHub (Dec 12, 2018):
Okay, it does sound like a client problem, but for now I updated the code to retry the device save operation. After @mprasil triggers a new build, you can try the new version.
@quthla commented on GitHub (Dec 13, 2018):
Thanks for all the support and quick reaction from you and mprasil.
Why are the Docker images built from mprasils repo rather than yours. The code is identical if I'm correct?
@mprasil commented on GitHub (Dec 13, 2018):
The image is now building.
@quthla, it's for historical reasons really. I've created the docker hub builds before they were official and a lot of people ended up using it, so we kept the
mprasil/bitwardendocker hub repo there. I was also using my github fork, because there were some docker hub specific things I needed to have on top of this repo here. This has since been merged, but as far as I know there's no way to change the upstream git repository in docker hub.. But yeah they are identical now.@quthla commented on GitHub (Dec 13, 2018):
@mprasil Not sure but maybe this'll will help: https://github.com/docker/hub-feedback/issues/313#issuecomment-265843090
@mprasil commented on GitHub (Dec 13, 2018):
Yeah, tried to follow that one, but it won't let me use repository other than mine.. Could be some permission on the GithHub side need to be set. But realistically it isn't that much of a burden the way it is now..
@dani-garcia commented on GitHub (Dec 16, 2018):
The 2FA mobile crash should be fixed now with the latest master, and with that I think this can be closed now. If anyone has logout issues, please reopen the issue.