Session expires immediately on login
novadeviator opened this issue · 54 comments
When I login with a confirmed and created user an interface flashes really quickly and I'm immediately logged out with an error by bitwarden - "Logged Out. Your login session has expired."
How can I debug this if this is a problem with js/css from yunohost?
I tried with safe-mode in FF and with completly fresh install of chromium-browser.
I guess it would be smart to try to install Bitwarden as public service - needing no YNH login - so there would be no overlay to test, but it takes ages to compile.
EDIT: is there a way to switch that bit on/off for publicly available app (no YNH login)?
I've just tested on a fresh bitwarden install, no problem to login.
On what Hardware your Yunohost is installed.
In which YunoHost version is installed ?
hetzner vps (64bit 2xVCPU, 4GB ram, 40GB disk)
debian 9
YunoHost 3.6.4.6 (stable).
I'm able to reproduce the bug, it's when you define is_public to no during the installation
yes. it makes sense. this is the same as the issue with Wekan. i'm ok with workaround to use public, but is it possible to change that parameter AFTER installation?
yes. it makes sense. this is the same as the issue with Wekan. i'm ok with workaround to use public, but is it possible to change that parameter AFTER installation?
I don't know, you should ask on the YunoHost matrix support channel
Bitwarden log error are:
bitwarden_rs[39102]: Error: Unauthorized Error: Invalid claim
bitwarden_rs[39102]: Warning: Responding with 401 Unauthorized catcher.
bitwarden_rs[39102]: Error: Response was a non-`Responder` `Err`: Os { code: 2, kind: NotFound, message: "No such file or directory" }.
bitwarden_rs[39102]: Warning: Responding with 500 Internal Server Error catcher.
bitwarden_rs[39102]: Error: Unauthorized Error: Invalid claim
bitwarden_rs[39102]: Warning: Responding with 401 Unauthorized catcher.
After disabling css/jss from YunoHost on a private bitwarden instance, still the same issue, seems more related to the SSO
The error now is:
bitwarden_rs[40270]: Error: Unauthorized Error: Invalid claim
bitwarden_rs[40270]: Warning: Responding with 401 Unauthorized catcher.
bitwarden_rs[40270]: Error: Response was a non-`Responder` `Err`: Os { code: 2, kind: NotFound, message: "No such file or directory" }.
bitwarden_rs[40270]: Warning: Responding with 500 Internal Server Error catcher.
bitwarden_rs[40270]: Error: Unauthorized Error: Invalid claim
bitwarden_rs[40270]: Warning: Responding with 401 Unauthorized catcher.
Following some investigation with @alexAubin , the cause of the issue is described here : YunoHost/issues#1420
From the app's side :
- The issue apparently only appears if you install a 'private' instance (is_public set to False). Installing in public mode should fix the issue if that's okay for you
- There is a dirty and unsecure workaround that we discussed with @alexAubin about bypassing the SSOwat mechanism for some URI
- The real fix should happen in the core (implement a new setting in our SSO mechanism to not mess with Authorization header)
- The real true ideal fix would be that this app (and others) support Basic HTTP auth ... but I'm not really expert about this stuff and don't know if that's even possible or relevant ... but that sounds necessary if we ever want to have an SSO integration for these
Hi, I got the exact same issue even if I installed bitwarden as a 'public' instance. Here is some background on my Yunohost installation :
Automatic diagnosis data from YunoHost
host: Debian 9.9
kernel: 4.14.17-xxxx-std-ipv6-64
packages:
yunohost:
repo: stable
version: 3.6.4.6
yunohost-admin:
repo: stable
version: 3.6.4
moulinette:
repo: stable
version: 3.6.4.1
ssowat:
repo: stable
version: 3.6.4
backports:
system:
disks:
root: Mounted on /, 19.1GiB (13.9GiB free)
sda3: Mounted on /home, 1.8TiB (689.8GiB free)
memory:
ram: 7.7GiB (4.8GiB free)
swap: 511.0MiB (511.0MiB free)
nginx:
- nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
- nginx: configuration file /etc/nginx/nginx.conf test is successful
Can you provide bitwarden logs after a failed login doing: sudo journalctl -u bitwarden | sudo /usr/bin/yunopaste and provide the link to the logs ?
Bitwarden_ynh package has been update, can you try to upgrade using: https://github.com/YunoHost-Apps/bitwarden_ynh and let me know if it solve the issue.
Bitwarden_ynh package has been update, can you try to upgrade using:
https://github.com/YunoHost-Apps/bitwarden_ynhand let me know if it solve the issue.
I did it. It does not improve the situation unfortunately.
Can you provide bitwarden logs after a failed login doing:
sudo journalctl -u bitwarden | sudo /usr/bin/yunopasteand provide the link to the logs ?
Please find below the link about the log :
https://paste.yunohost.org/uniladibaz
I'm having the same problem. I originally installed the application as private and had this problem. After reading here, I removed the app, then re-installed it as public, but I'm having the issue again.
Logs:
journalctl -u bitwarden(note, those logs are from both the initial installation and re-installation)- /var/log/nginx/vault.wallace.fm-access.log
- /var/log/nginx/vault.wallace.fm-error.log
The nginx access log shows the requests that are failing with 401s:
- GET /api/sync?excludeDomains=true
- POST /notifications/hub/negotiate
Some random notes that might be illuminating or a complete waste of time:
- The public installation doesn't seem to be different than the initial private one. The default settings still disallow sign-ups. Maybe the settings were cached somewhere, so re-installing it as public didn't actually change anything?
- Since sign-ups are disabled, I logged in as the admin and invited myself to create an account. After going through that process, the last step is to log into the new account. I log in, then am immediately logged out again, and I see two pop-up messages:
- Didn't get it copied, and can't get it back, but it said said something like "The admin must approve your account before you can log in"
- "Logged out. Your session has expired"
I also had this problem yesterday.
Installed as a private app then as a public, no changes.
I tried whitelisting my domain on every ad-blocker add-ons, even disabling some of them, nothing.
However, as my day to day firefox dev is heavily modified, I tried to login in from a fresh firefox install and… it worked!
I tried to change settings one by one on the fresh install to see which one was breaking the login but no luck.
Then I went home and tried again today: I don't have the problem anymore, anywhere.
The only difference is that I activated 2FA (from the working fresh install).
Can't say if it's related or if restarting my browser/computer changed something (cache maybe?).
I can provide some logs but I don't know which one. Ask if you need, I'll be happy to provide!
Narduin, I tried to connect on a different computer and it worked. I do not know why. But I still have the issue on the first computer. I removed Firefox and reinstall it but it did not change anything. I may have to dig deeper on that.
After few hours without any issued it is back. If I remove the cookies related to bitwarden it allows me to connect again. But if I forbid the coockies from bitwarden (meaning the cookies from my Yunohost server) I cannot connect to my Yunohost server.
Interesting. I just tried logging in with a different browser (Chrome) and I got in just fine, but when I try with my normal browser (Firefox), I still get the error. I had never signed into my yunohost instance from Chrome (no Yunohost logo in the bottom right corner). I was able to log out and log in as much as I wanted.
Going off of @valentinbesse's comment, I logged into yunohost, then tried to navigate around Bitwarden, but it kicked me off saying my session expired. Now I can't log in anymore (the Yunohost logo is now visible in the bottom right corner).
So yeah, I'd say it definitely looks like it has something to do with the yunohost cookies
Edit: Also, once I logged out of yunohost, I was able to log back into bitwarden
So yeah, I'd say it definitely looks like it has something to do with the yunohost cookies
Edit: Also, once I logged out of yunohost, I was able to log back into bitwarden
If you really are interested in understanding what happens, then please read YunoHost/issues#1420
My understanding is that it's not related to cookies, and you can't really understand what's happening without taking a look into SSOwat and the fact that it intercepts the request and add Authentication header before passing it to the app...
Hello !
Same problem here, I can stay logged in only if I'm logged out of Yunohost. Tell me if you need other info.
Congrats for the package though, it works like a charm beside this problem !
Edit: Same problem on public instance.
I also am having the same issue on a public instance
I have the same issue in a non-public instance. Is there any fix known yet other than making the instance public?
Solved this problem by commenting access_by_lua_file /usr/share/ssowat/access.lua; in the respective ngnix conf for your domain.
This is the same error I had with mastodon on Yunohost
Hmm. It doesn't work for me.
I removed (-> commented) the entry "access_by_lua_file" in the nginx configuration file responsible for the Bitwarden sub domain (/etc/nginx/conf.d/bitwarden.sub.domain.conf) and reloaded the nginx service (service nginx reload). However I am still being logged out of Bitwarden when I am logged in to Yunohost. My instance is a public installation which I guess is mandatory for this fix?
No I didn't ... I skimmed the file but didn't see any access_by_lua_file option for port 443. I checked it more carefully and removed the option for port 443 as well. It is working now.
Hmm. It doesn't work for me.
I removed (-> commented) the entry "access_by_lua_file" in the nginx configuration file responsible for the Bitwarden sub domain (/etc/nginx/conf.d/bitwarden.sub.domain.conf) and reloaded the nginx service (service nginx reload). However I am still being logged out of Bitwarden when I am logged in to Yunohost. My instance is a public installation which I guess is mandatory for this fix?
It's normal. You have to be logged out of YunoHost.
@yalh76
Please read @hieronymousch comment from 7 days ago. The fix is working. I guess this configuration should be the default configuration for "Public Instance" installations.
Solved this problem by commenting access_by_lua_file /usr/share/ssowat/access.lua; in the respective ngnix conf for your domain.
This is the same error I had with mastodon on Yunohost
So does this can be subject to a PR maybe ?
@yalh76
Please read @hieronymousch comment from 7 days ago. The fix is working. I guess this configuration should be the default configuration for "Public Instance" installations.
It would be just a workaround, it would be better to solve YunoHost/issues#1420
Running a public instance which is otherwise working great (thanks for everyone's hard work!) but I can confirm that if I'm logged into yunohost I get this error, and if I fully log out of YNH I don't get it. Will try some of the above workarounds.
Same problem, and it works when i logout from YNH.
I installed it as a non-public application and now I have this same problem.
I've already commented on the recommended line in nginx settings but nothing has changed.
Any way to make the application public after installation? When I access the application's url, I'm redirected to the yunhost login page.
As far as I know: you have to remove the current app installation and install it again as a public app.
I guess you can't really change. I tried that:
ynh_app_setting_set bitwarden unprotected_uris "/"
sudo yunohost app ssowatconf
sudo systemctl reload nginx
did not work
Hello everyone. just faced the same issue. Private variant also does not allow to use default bitwarden apps. so actually I assume it would be much better to remove such possibility (install as private). Since it is very inconvenient to work only with web access with passwords without apps.
Also just checked that it is still logs-out immediately if you are logged in yunohost itself.
Found how to workaround issue above:
File: /etc/ssowat/conf.json
"skipped_urls": [
"your.yunohost.url/bitwarden",
"your.yunohost.url/yunohost/admin",
"your.yunohost.url/yunohost/api"
],
Hello everyone. just faced the same issue. Private variant also does not allow to use default bitwarden apps. so actually I assume it would be much better to remove such possibility (install as private). Since it is very inconvenient to work only with web access with passwords without apps.
Also just checked that it is still logs-out immediately if you are logged in yunohost itself.
Found how to workaround issue above:
File: /etc/ssowat/conf.json "skipped_urls": [ "your.yunohost.url/bitwarden", "your.yunohost.url/yunohost/admin", "your.yunohost.url/yunohost/api" ],
Yes it's a good workaround.
For information a solution is on the way that will solve the issue for bitwarden but also for other apps: YunoHost/yunohost#883
But making that you application is public....
One small comment: if you use dedicated domains, the url will (of course) be different and will be lilke bitwarden.yourdomain.com , bitwarden.yourdomain.com/admin bitwarden.yourdomain.com/api
One small comment: if you use dedicated domains, the url will (of course) be different and will be lilke bitwarden.yourdomain.com , bitwarden.yourdomain.com/admin bitwarden.yourdomain.com/api
But that's new to the actual version. You can now install bitwarden at https://mydomain.org/bitwarden wasn't the case before
Hi,
Same problem here, but the workaround using skipped_urls did not worked.
I changed into ssowat.conf.persistent, then yunohost app ssowatconf. Is it enough or am i missing something ?
Hi,
Same problem here, but the workaround using skipped_urls did not worked.
I changed into ssowat.conf.persistent, then yunohost app ssowatconf. Is it enough or am i missing something ?
You should not install bitwarden as a private application until YunoHost/issues#1420 is solved...
It was not. As for the mastodon app, setting app as public is not enough.
The only working fix for me is commenting ssowat configuration in nginx vhost.
Have you also tried from a different browser or after being logout from YunoHost ?
It is ok when user is disconnected from Yunohost.
Seems nothing different from the bug other users are facing. Will keep the fix in nginx vhost file until YunoHost/yunohost#883 is here.
Thank you @yalh76 :-)
Hello, I updated to version 1.15.1~ynh2 and this problem still occurs. How could I help you to find the root cause ?
The root cause is known: YunoHost/issues#1420
SSOWAT sending headers that bitwarden try to interpretate....
Hello everyone. just faced the same issue. Private variant also does not allow to use default bitwarden apps. so actually I assume it would be much better to remove such possibility (install as private). Since it is very inconvenient to work only with web access with passwords without apps.
Also just checked that it is still logs-out immediately if you are logged in yunohost itself.
Found how to workaround issue above:
File: /etc/ssowat/conf.json "skipped_urls": [ "your.yunohost.url/bitwarden", "your.yunohost.url/yunohost/admin", "your.yunohost.url/yunohost/api" ],Yes it's a good workaround.
For information a solution is on the way that will solve the issue for bitwarden but also for other apps: YunoHost/yunohost#883
But making that you application is public....
This worked fine but I also had to remove any permission for bitwarden for all of my users / groups except visitors in the authorizations page (/yunohost/admin/#/groups)
Florent
Hello everyone
I just saw that YunoHost/yunohost#861 has been merged since 30th Oct, so we just have to wait the next 4.1 release which will provide the fix. Many thanks to @Josue-T and @alexAubin
Can't wait to have this Bitwarden login issue fixed🤞
The fix has landed with version 4.1.
Am I wrong if I say that, in order to workaround this issue, we should set auth_header to false for bitwarden in /etc/ssowat/conf.json until there is a proper fix or option brought by the bitwarden ynh app?
(This workaround is not very clean: after any package installation, it will be overridden, but maybe that's OK if a fix or option is introduced in bitwarden app quickly)
Florent
The fix has landed with version 4.1.
Am I wrong if I say that, in order to workaround this issue, we should set
auth_headerto false for bitwarden in/etc/ssowat/conf.jsonuntil there is a proper fix or option brought by the bitwarden ynh app?(This workaround is not very clean: after any package installation, it will be overridden, but maybe that's OK if a fix or option is introduced in bitwarden app quickly)
Florent
I didn't have the time to deep dive into 4.1 and new permissions, but there would be a solution for the auth header issue causing the session expires immediately on login
Any news with this bug? I have the same on my yunohost instance.
thank you so much for this bugfix