View Issue Details

This bug affects 1 person(s).
 2
IDProjectCategoryView StatusLast Update
19595Bug reportsPluginspublic2024-09-26 21:49
Reportermifritscher Assigned Totibor.pacalat  
PrioritynoneSeveritypartial_block 
Status feedbackResolutionopen 
Product Version6.5.x 
Summary19595: Auth and AuthLDAP: different case sensitivy
Description

AuthLDAP is case insensitive regarding the username, whereas Limesurvey itself is.

This leads to double accounts in LimeSurvey if someone uses both e.g. MichaelMustermann and michaelmustermann.

Steps To Reproduce

Steps to reproduce

Configure LDAP. Use multiple variants of the loginname (MichaelMustermann and michaelmustermann)

Expected result

Creation of one account. Either both variants are able to login, or the "wrong" variant is blocked.

Actual result

Creation of two accounts.

TagsNo tags attached.
Bug heat2
Complete LimeSurvey version number (& build)6.5.11+240605
I will donate to the project if issue is resolvedNo
Browser
Database type & versionPostgreSQL 13.14-0+deb11u1
Server OS (if known)Debian 11
Webserver software & version (if known)Apache 2.4.59-1~deb11u1
PHP Version7.4.33

Users monitoring this issue

There are no users monitoring this issue.

Activities

gabrieljenik

gabrieljenik

2024-08-05 16:50

manager   ~80741

I think this ticket is not a good fit to be assigned.
No experience with LDPA. Not used to working on identity flows and related stuff either.
Maybe someone else can review it?

Having said that, please find some analysis below.

Analysis

I suppose that to start with, when creating the user in Lime (during auto-creation) it should be done in lowercase. And then, when logging in and setting the “identity”, it should be done in lowercase as well.

The problem with that is that if someone usually uses uppercase, and already has a user in Lime with uppercase, it could become a problem.

To avoid that happening, you should create the user in lowercase, and in login look for one that matches exactly or, if it doesn't match, try with lowercase. But it doesn't seem like a good idea to let it work like that.

Issue History

Date Modified Username Field Change
2024-06-09 11:29 mifritscher New Issue
2024-07-16 16:38 tibor.pacalat Assigned To => gabrieljenik
2024-07-16 16:38 tibor.pacalat Status new => assigned
2024-08-05 16:50 gabrieljenik Note Added: 80741
2024-08-05 16:50 gabrieljenik Bug heat 0 => 2
2024-09-26 21:49 gabrieljenik Assigned To gabrieljenik => tibor.pacalat
2024-09-26 21:49 gabrieljenik Status assigned => feedback