Skip to content
GitLab

unexpected persistent sessions appear since 2.0.10

Concerned version

Version: %2.0.11

Platform: (Nginx/Apache/Node.js)

Summary

This is a regression caused by #2243 (closed) , see also #1869 (closed)

  • Enable brute force protection
  • Login with UPPERCASE login and normal password (on a case insensitive backend such as LDAP)
  • Watch an UPPERCASE persistent session being incorrectly created by the BruteForceProtection plugin
  • This session is not used elsewhere, but it pollutes the session storage, and one of my customers is reporting that they cause a lot of justified confusion for their user support teams.

Logs

Issue comes from setPersistentSessionInfo, the following lines

my $key = $req->{sessionInfo}->{ $self->conf->{whatToTrace} } || $user;

incorrectly assumes that $_user can be used as the persistent storage identifier, but it is not always the case. In the default config, we use a complex macro instead.

Possible fixes

That's a hard problem. Quoting #2243 (closed):

I would expect that the plugin detects that the account is locked before calling the authentication backend.

That is not possible to do with persistent sessions. Our default configuration ships with whatToTrace = _whatToTrace, which is a macro, and macros aren't available until setSessionInfo has run, and setSessionInfo is run after getUser and authenticate, which is what #2243 (closed) is about.

It looks like we have two possible options:

  • Rollback #2243 (closed)
  • Rewrite the BruteForceProtection plugin to no longer use psessions. But that is a lot more work.

Changing psessions to be fully based on _user instead of whatToTrace would break too many installs to consider.

Edited by Maxime Besson