Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • lemonldap-ng lemonldap-ng
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 311
    • Issues 311
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 6
    • Merge requests 6
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LemonLDAP NGLemonLDAP NG
  • lemonldap-nglemonldap-ng
  • Issues
  • #2482
Closed
Open
Issue created Mar 08, 2021 by Maxime Besson@maxbes🔧Maintainer

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 Mar 08, 2021 by Maxime Besson
Assignee
Assign to
Time tracking