snipe-it auto-loggs out other sessions

[axkibe]

In our installation snipe-it whenever I log in one browser, it will always logout all other browser sessions. This is mildly annoying, as for example using a desktop to make changes and a smartphone as QR-Code reader to identify devices.

I cannot tell if this is by design, by configuration or by accident.

I looked at the source code for a few hours and cannot see anything that should do this on purpose, but with laravel this gets through a few layers of code and I'm a total newbe. The only instance I found on purpose "Auth::logoutOtherDevices" is on passwort change.. which makes a lot of sense, but why does it already auto logout any old session on login?

Is this on purpose (which can be turned off?), or is this misconfiguration on our side perhaps?

[snipe]

That's definitely not a thing we're doing. There is an env var (I don't know who or how your stuff was set up): https://snipe-it.readme.io/docs/configuration#optional-session-settings EXPIRE_ON_CLOSE and another one SESSION_LIFETIME you might want to look at, but's a config issue or possible a network issue (if you have clever network people trying to prevent shadow IT)

[snipe]

• https://github.com/snipe/snipe-it/blob/master/app/Http/Controllers/Auth/LoginController.php handles the login
• https://github.com/snipe/snipe-it/blob/master/app/Http/Kernel.php - points to the library middleware that handles authorization and authentication

[gettalong]

Thanks! That helped a bit. I was able to confirm that including \Illuminate\Auth\Middleware\Authenticate::class the request->user() object is available and correct. So something after that must log out the user and perform the redirect to login. What is run after that last middleware?

[snipe]

Just the normal application stack. The only place we invoke a logout is here:

snipe-it/app/Http/Controllers/Auth/LoginController.php

Lines 452 to 499 in 931ab10

	public function logout(Request $request)
	{
	// Logout is only allowed with a http POST but we need to allow GET for SAML SLO
	$settings = Setting::getSettings();
	$saml = $this->saml;
	$samlLogout = $request->session()->get('saml_logout');
	$sloRedirectUrl = null;
	$sloRequestUrl = null;
	// Only allow GET if we are doing SAML SLO otherwise abort with 405
	if ($request->isMethod('GET') && !$samlLogout) {
	abort(405);
	}
	if ($saml->isEnabled()) {
	$auth = $saml->getAuth();
	$sloRedirectUrl = $request->session()->get('saml_slo_redirect_url');
	if (! empty($auth->getSLOurl()) && $settings->saml_slo == '1' && $saml->isAuthenticated() && empty($sloRedirectUrl)) {
	$sloRequestUrl = $auth->logout(null, [], $saml->getNameId(), $saml->getSessionIndex(), true, $saml->getNameIdFormat(), $saml->getNameIdNameQualifier(), $saml->getNameIdSPNameQualifier());
	}
	$saml->clearData();
	}
	if (! empty($sloRequestUrl)) {
	return redirect()->away($sloRequestUrl);
	}
	$request->session()->regenerate(true);
	if ($request->session()->has('password_hash_'.Auth::getDefaultDriver())){
	$request->session()->remove('password_hash_'.Auth::getDefaultDriver());
	}
	Auth::logout();
	if (! empty($sloRedirectUrl)) {
	return redirect()->away($sloRedirectUrl);
	}
	$customLogoutUrl = $settings->login_remote_user_custom_logout_url;
	if ($settings->login_remote_user_enabled == '1' && $customLogoutUrl != '') {
	return redirect()->away($customLogoutUrl);
	}
	return redirect()->route('login')->with(['success' => trans('auth/message.logout.success'), 'loggedout' => true]);
	}

And on a restore (where everyone gets logged out), and in the CheckUserIsActivated middleware.

[gettalong]

Thanks again for the pointers! I found the culprit.

Using php artisan route:list -vvv --path=admin I found that after \Illuminate\Auth\Middleware\Authenticate the Illuminate\Session\Middleware\AuthenticateSession middleware is run before the application stack.

And inside the handle() method the following part logs the user out:

https://github.com/laravel/framework/blob/11.x/src/Illuminate/Session/Middleware/AuthenticateSession.php#L63-L65

I'm not sure why the password hash changes, though, since the password didn't change. However, after disabling "LDAP Password Sync" it now works and I can login multiple times concurrently!

[snipe]

Great sleuthing! We wouldn't know that the password didn't change though, since if you bcrypt the same text 100, the hash will change each time. We honestly may deprecate LDAP password syncing anyway. Most LDAP systems are pretty stable these days, and since most are in the cloud for many of our users, if they cannot contact the LDAP system, they have bigger problems anyway.