User login is stored in DB differently since upgrading, when created vía delegated authentication

SonarQube 9.9 LTS (any version)

  • User login is stored in DB differently since upgrading, when created vía delegated authentication.

A customer of us has upgraded their instance from 8.9 to 9.9 LTS. They use delegated authentication via LDAP.

So far when a user logged in, they logged in with their corporate user ID (consisting of one letter and six numbers, for example: y293842). A user was created in SonarQube whose login was y293842.

Now, when a new user is created, they are created with the login: real user name + random numbers, like this: bastardo-mario19238.

I have been looking at the code in the SonarQube repository and indeed it seems that the way of mapping the user from LDAP has been changed, for example:

This change, does not affect the functionality, but it has already made me suspicious and review other changes and look for info. I know that DAOs with which the users are stored in DB have also changed, but I can’t find where.

I have been looking at documentation at LDAP and we have no way to control how we want the user UID to be inside the SonarQube DB. There are customers who were creating users with their particular UID and suddenly they are being stored with a randomly generated another. If they have some kind of script/application that makes automatic operations through the API with the “login” parameter, they have to make changes in those developments.

I have found this Jira ticket for this change: [SONAR-17508] - Jira and it made me think: Is it expected that in the future we can have some parameter to control how users are mapped from the different sources of delegated authentication?

Thank you, regards,

Hi Mariote,

We believe the DB should be treated as a black box. :smiley:

Thus there are no promises about forward/backward compatibility. Users are welcome to use public Web APIs, but we make no guarantees about how data is stored in the DB.


No, it’s OK, G Ann.

We found that they just have to switch from reading “login” param to “externalIdentity” in the api/users/search api calling in their developments.

That was the reason for requesting this post earlier.

It’s inconvenient, but it doesn’t mean the world.