Caught in a login loop

I just upgraded my passbolt, and now I’m stuck in a login loop. The login screen shows as it should, but as its trying to log me in the page flashes a firefox error saying that I need an addon, then takes me back to the login page. I clearly have the addon, or I wouldn’t even be able to try to log in, and it is also the latest version. Health checks all pass too.


Healthcheck shell

Environment

[PASS] PHP version 7.0.30-0+deb9u1.
[PASS] PCRE compiled with unicode support.
[PASS] The temporary directory and its content are writable.
[PASS] The public image directory and its content are writable.
[PASS] The logs directory and its content are writable.
[PASS] GD or Imagick extension is installed.
[PASS] Intl extension is installed.
[PASS] Mbstring extension is installed.

Config files

[PASS] The application config file is present
[PASS] The passbolt config file is present

Core config

[PASS] Debug mode is off.
[PASS] Cache is working.
[PASS] Unique value set for security.salt
[PASS] Full base url is set
[PASS] App.fullBaseUrl validation OK.
[PASS] /healthcheck/status is reachable.

SSL Certificate

[PASS] SSL peer certificate validates
[PASS] Hostname is matching in SSL certificate.
[WARN] Using a self-signed certificate

Database

[PASS] The application is able to connect to the database
[PASS] 19 tables found
[PASS] Some default content is present
[PASS] The database schema up to date.

GPG Configuration

[PASS] PHP GPG Module is installed and loaded.
[PASS] The server gpg key is not the default one
[PASS] The environment variable GNUPGHOME is set to /home/www-data/.gnupg.
[PASS] The directory /home/www-data/.gnupg containing the keyring is writable by the webserver user.
[PASS] The public key file is defined in config/passbolt.php and readable.
[PASS] The private key file is defined in config/passbolt.php and readable.
[PASS] The server key fingerprint matches the one defined in config/passbolt.php.
[PASS] The server public key defined in the config/passbolt.php is in the keyring.
[PASS] There is a valid email id defined for the server key.
[PASS] The public key can be used to encrypt a message.
[PASS] The private key can be used to sign a message.
[PASS] The public and private keys can be used to encrypt and sign a message.
[PASS] The private key can be used to decrypt a message.
[PASS] The private key can be used to decrypt and verify a message.
[PASS] The public key can be used to verify a signature.

Application configuration

[PASS] Using latest passbolt version (2.1.0).
[PASS] Passbolt is configured to force SSL use.
[PASS] App.fullBaseUrl is set to HTTPS.
[PASS] Selenium API endpoints are disabled.
[PASS] Search engine robots are told not to index content.
[PASS] Registration is closed, only administrators can add users.
[PASS] Serving the compiled version of the javascript app
[PASS] All email notifications will be sent.

No error found. Nice one sparky!

@mayday010 could you try to delete the cookies in your browser for that domain and retry? It’s possible you were still logged in the previous version and the cookie is not getting cleared by the v2.

That didn’t work. Its still looping.

It looks like an issue with sessions, if it’s not the cookie i’m not sure what it could be.

Can you provide more information, like:

  • Which browser are you using?
  • Do you have the same behavior with another browser / another user?
  • Can you explain in detail the “loop” process you are seeing, e.g. does it redirect you first to https://yourdomain.com/ and then again on the login page? Or does it stay on the login page without reloading.
  • Can you check the network tab in your browser console and check for the responses.
  • Do you have any error in your browser console?
  • Do you have anything in your error log on your server?
  • I’m using firefox.
    -I’m the only user
  • Yes, the looping process is exactly as you described. After entering the password, the cog wheel spins as if it were logging me in. Then it tries to load the root page, and redirects back to the login.
  • The network tab reflects the process as described, I see a 302 redirecting to the login page
  • Console doesn’t show any errors, but there is a warning of “Strict-Transport-Security: The connection to the site is untrustworthy, so the specified header was ignored.”
  • There’s nothing in the error log. But if it helps to trace it down, here is a copy of the access log entries.

192.168.10.10 - - [27/Jul/2018:08:29:45 -0500] “POST /auth/login.json?api-version=v1 HTTP/1.1” 200 3345 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”
192.168.10.10 - - [27/Jul/2018:08:29:46 -0500] “POST /auth/login.json?api-version=v1 HTTP/1.1” 200 4670 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”
192.168.10.10 - - [27/Jul/2018:08:29:46 -0500] “GET /account/settings.json?api-version=v2 HTTP/1.1” 404 424 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”
192.168.10.10 - - [27/Jul/2018:08:29:46 -0500] “GET /auth/checkSession.json?api-version=v1 HTTP/1.1” 403 1171 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”
192.168.10.10 - - [27/Jul/2018:08:29:46 -0500] “GET / HTTP/1.1” 302 1066 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”
192.168.10.10 - - [27/Jul/2018:08:29:46 -0500] “GET /auth/login HTTP/1.1” 200 3074 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”
192.168.10.10 - - [27/Jul/2018:08:29:47 -0500] “GET /settings.json?api-version=v2 HTTP/1.1” 200 1376 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”
192.168.10.10 - - [27/Jul/2018:08:29:47 -0500] “POST /auth/verify.json?api-version=v1 HTTP/1.1” 200 2929 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0”

Hello,

Then I’m pretty sure it’s an issue with the sessions. You can clear the session cache on the server side see if that solves it (by restarting apache ro nginx). Otherwise you can try with another session engine: Sessions - 3.10

The only place I see mention of an engine is in this example.

‘Session’ => [
‘defaults’ => ‘database’,
‘handler’ => [
‘engine’ => ‘ComboSession’,
‘model’ => ‘Session’,
‘cache’ => ‘apc’
]
],
// Make sure to add a apc cache config
‘Cache’ => [
‘apc’ => [‘engine’ => ‘Apc’]
]

What engine options are available? Will changing the engine mean I have to use a different model, and or cache option, if so what options do I have? And in this example the default is database. Do I need to change it to database, or are there other options?

I had a similar issue when I upgraded. My problem was that the permissions required for the different directories was incorrect.

I had to do a few things since I am using SELinux. I reset all permissions first.

# Restablish the SELInux context:
sudo restorecon -Rv /var/www/passbolt
sudo restorecon -Rv /var/lib/php/fpm
# Change the owner of the webroot:
sudo chown -R nginx:nginx /var/www/passbolt
sudo chown -R nginx:nginx /var/lib/php/fpm/
# Change basic permissiones:
sudo chmod -R g+w /var/www/passbolt
sudo chmod g+s /var/www/passbolt
# Establish SELinux permissions:
sudo chcon -Rt httpd_sys_content_t /var/www/passbolt
sudo chcon -Rt httpd_sys_rw_content_t /var/www/passbolt/logs
sudo chcon -Rt httpd_sys_rw_content_t /var/www/passbolt/tmp
sudo chcon -Rt httpd_sys_rw_content_t /var/www/passbolt/webroot/img/public/
sudo chcon -Rt httpd_sys_rw_content_t /var/lib/php/fpm

I’m using nginx and php-fpm - both running as nginx user. So, the /var/lib/php/fpm directory was owned by php-fpm instead of nginx (changed that and it fixed my looping issue after upgrade.)

Note: I was looking as why my avatar images weren’t uploading - and by answering this I noticed I hadn’t done the something which I’ve added to the notes above and is now working.


Patrick

Patrick, I appreciate the tips, but I’m not currently using selinux, nor nginx.

@mayday010. As you’re upgrading your passbolt there is a small chance that it comes from the Firefox third party cookies settings, but better to be sure. Can you check that your Firefox “accept[s] third-party cookies and site data”.

1 Like

Cedric, thanks much, it was a cookie issue. As someone who takes basic steps (such as blocking cookies) to prevent things like internet tracking, why is this application written to require a third party cookie? Do you know which site(s) are need to write cookies? I’d like to add them to the exceptions instead of blindly allowing cookies.

Excellent! You can add an exception for the domain your passbolt instance is running on.
See : https://github.com/passbolt/passbolt_api/issues/177#issuecomment-333467502

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.