-
Improvement
-
Resolution: Unresolved
-
Major
-
git plugin 1.1.6
git plugin 2.0, jenkins 1.540, ubuntu 13.10
-
Powered by SuggestiMate
I realize mapping git author/commit users back to Jenkin's users is pain, but perhaps it could be done a little better.
Some ideas:
- Try looking up a user's email and comparing that.
- Using the user portion from the email (e.g. someuser@example.com becomes someuser).
- Looking up the user's email in LDAP, if LDAP is being used.
The last would be ideal for us.
Ciao!
- is duplicated by
-
JENKINS-43178 “Unregistered user” warning skipping addresses under inappropriate conditions
-
- Open
-
-
JENKINS-42951 Local-part based user mapping results in confused changelogs
-
- Open
-
-
JENKINS-43386 Not sending mail to user with permission to view
-
- Open
-
-
JENKINS-43759 Not sending email to registered users
-
- Open
-
-
JENKINS-43268 Can't send email to registered users
-
- Closed
-
-
JENKINS-41451 git-plugin: user accounts are looked up by their name
-
- Closed
-
- is related to
-
JENKINS-10258 Allow users unicity
-
- Open
-
-
JENKINS-49979 Showing only Jenkinsusers in Assignee Selectbox
-
- Closed
-
[JENKINS-9016] Git creates usernames based on 'name' not the email.
Integrated in plugins_git-plugin #119
[FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.
Andrew Bayer : 3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
Files :
- src/main/java/hudson/plugins/git/GitChangeSet.java
Code changed in jenkins
User: Andrew Bayer
Path:
src/test/java/hudson/plugins/git/AbstractGitTestCase.java
http://jenkins-ci.org/commit/git-plugin/12515a33b7ae0e8030fbc61575e6cd445850ceb2
Log:
Fixing test failures due to JENKINS-9016 fix.
I'm still having issues with this.
In my setup, we use ldap for authentication. The ldap username has almost no similarity to the author name or email in our git commits (we use full and proper "Firstname Lastname <Firstname.Lastname@Companyname.com>" for that).
What would work is searching for existing users by email address rather than using the email segment as a username, since the ldap plugin does properly set the email field to the same address as is listed in the git commit (assuming case insensitivity).
I agree with Joel's comment.
In our setup, only users changing their full name in Jenkins to match the one in Git have their commits associated. Other people have two "accounts": the one they use to authenticate (LDAP) and the one automatically created with Git commits.
Using the e-mail address to do the mapping seems to be a better solution.
I have created some initial code on this subject. The only question that remains is whether the plugin is the right place for my UserEmailResolver.
I also had some troubles getting the tests going and had to add a newer jenkins-core, ui-samples-plugin, jenkins-test-harness and javadoc to the dependencies.
https://github.com/vStone/git-plugin/commit/63612268d832edc7a77d0be55e650e31fc5442a9
In my setup I have users authenticated against corporate Active Directory, which works nice along with LDAP email plugin (email addresses get resolved correctly). User ids look something like 123456, and as such are defined in Global Security. Real user names do get resolved correctly from those numeric ids.
Unfortunatelly, when it comes to build changes list of the git based projects, the real user names do not get resolved correctly as they do not contain those numeric ids any more. For the commiter/author "Dominik Drzewiecki <dominik.drzewiecki@acme.com>" which is a concatenation of git user.name and user.email configuration parameters I get the changelog entry commited by dominik.drzewiecki which cannot be futher resolved either against AD (id) or LDAP (email). It seems that Jan's patch that adds one extra resolution step would do the trick.
The only two "modes" at the moment (v2.0) seem to be either user.name or user.email not the username from user.email? The latter being the suggested default "mode" in v1.1.7:
If no Jenkins user is found for a commit's user.name value, strip the username from "username@domain.com" from the user.email value and use that instead.
We want users to be associated with just their username not their full email and not their user.name so that other things can automatically work, e.g. the Jabber Plugin. Also, the users log in, via LDAP, with just their username.
The unique identifier in git is the e-mail address so matching towards a Jenkins account on user name is really bad. In some cases, like for example push-review tests with Gerrit, you do not need to match to a Jenkins account at all, just use the e-mail address in the commit when sending feedback.
Option #1 (Try looking up a user's email and comparing that.) is definitely the way this should be implemented.
Option #3 (Looking up the user's email in LDAP, if LDAP is being used.) would be a great bonus.
Option #2 (Using the user portion from the email (e.g. someuser@example.com becomes someuser).) is just as bad is matching on user name and solves nothing.
We are a big company with a lot of people, some do have the exact same names so now we have users getting e-mail feedback on git commits they are not the author of.
Problem still persists.
In my company users are uniquely identified by their email adress not their user.name, so extracting the user name from the email does not work either. Any plans when to fix that?
I have seen that the issue had some activity recently. (I came here due to JENKINS-43178.)
I agree with epkabeg and joel. I would really be happy if the issue could be fixed as proposed in option #1 and #3.
Btw. there is already this global plugin option that uses the full email address:
Create new accounts based on author/committer's email
As git changelog is parsed to identify authors/committers and populate Jenkins user database, use email as ID for new users.
With the recent security fixes (e.g. JENKINS-43178) the situation is getting even worse.
Looking up a user based on it's configured email-address should solve so many problems.
Expecting to have the login user names matching exactly the mail adress before the @ is just too restrictive. Guess someone changing it's mail but keeping it's account or like in my company having short login names (coming from ldap) contrary to long mail addresses.
abayer please consider raising the priority of this task!
I second the Option #1 (and #3) above.
We are authenticating against LDAP and have rather arbitrary Jenkins user id s- e.g. fuu12bar5.
The only thing the "real" LDAP users and the git users have in common is the email address (if you are willing to compare it case insensitive).
Is this the right part of the code?
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L387
There is a really old pull request, mentioned in this comment, might this be still useful?
I came to the situation described by others here, in our case jenkins users being handled using Active Directory (AD) and commit information coming from GIT (Bitbucket). For a user with my username (Jose Camacho), commit information from GIT included in "Author" part would have the username defined as jose.camacho but users in AD are created using acronyms like jocam (for jose camacho).
My Email address is matched with both users (jose.camacho and jocam), and when trying to send out emails to me, it detects that the user name is jose.camacho (and not jocam!) and when using the realm validation mechanism (AD), AD says "not existing user" and the message "Not sending mail to unregistered user" appears.
For the options that epkabeg suggested, I also second Option #1: If there is any kind of user with that email address, why should it be declared as "unregister user"?
– Workaround
Anyway, we are sending Emails from Jenkinsfile using emailext and we did not want to change that way of using Jenkins so we are using right now a "workaround".
We know that the Emails information coming from GIT is correct (close, controled environment) so we disable the "not sending mail to unregistered user" by using a variable included in the EmailExt plugin version 2.58, introducing following code:
def currenVal = RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS
RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = true
// Send Email with emailext
RecipientProviderUtilities.SEND_TO_UNKNOWN_USERS = currenVal
(this needs to include import hudson.plugins.emailext.plugins.recipients.* and also needs a securiy confirmation)
I know, it is not the better solution, but it works. Hope this helps anyone looking for a workaround.
jose_camacho we have a very similar setup in my company. We also see that multiple users with the same email are created (one from AD when the user loges in, the other from git plugin).
What we found was that having the git authors name matching the AD displayName seems to associate the users correctly (that can be seen in the projects changes too). If i remember correctly, when you are using Bitbucket with AD, you can enforce that name matching in all commits.
Still a matching based on the email adress would be so much more convenient.
EDIT: rechecked the association and it seems to work only in special cases, that i have to investigate further, as of today we are stuck to the system property to allow everything too.
We struggle on this issue too and in my opinion this ist not a minor issue, it's more an incident! Actually the issue is some kind of a show stopper as the user did not receive proper notifications anymore.
Code changed in jenkins
User: George
Path:
src/main/java/hudson/plugins/emailext/ExtendedEmailPublisherDescriptor.java
src/main/java/hudson/plugins/emailext/plugins/recipients/RecipientProviderUtilities.java
src/main/resources/hudson/plugins/emailext/ExtendedEmailPublisher/global.groovy
src/main/webapp/help/globalConfig/allowUnregistered.html
http://jenkins-ci.org/commit/email-ext-plugin/19081b2aa3d32c479125b538c545fdd3065960f8
Log:
JENKINS-43268 adding global checkbox to allow sending to unregistered emails. This is a workaround to a SCM plugin issue, like JENKINS-9016 and probably others (#161)
Would it be possible to have some kind of 'domain filter' when you enable the 'Allow sending to unregistered users' checkbox?
For instance: allow sending mails to contributers to a git repo that don't have a Jenkins account, but that do have an email address set up that ends with '@domain.com'.
This would be interesting so that when we're using open source git(hub) repositories we don't accidentally sent out mails to the contributers there, when one of our builds fail.
Can't the e-mail address(es) in the commit message be used to find Jenkins security realm users?
The e-mail address in my commit messages is the same as the e-mail address associated with my Jenkins account. Why can those not be matched up?
I agree with everyone else here. We just started converting from old jobs to Pipeline jobs and are now faced with issues surrounding user mapping. I'll admit, it's probably more due to the fact we updated our 3 years old Jenkins instance.
The unique identifier IS the email address. This is what should be used for mapping with registered Jenkins user. As many others, our company use shorthand names for login in AD, yet in Git all our users configure their full name. This is a common practice in the corporate world at it makes it easy to login everywhere with a shorter name. In my case it's even a lifesaver.
Imagine if I had to type "Jeremie.Faucher-Goulet" every time I log in somewhere, instead of the much easier "jfaucher" I use against AD in all login forms everywhere.
Even Fisheye+Crucible from Atlassian is able to do proper mapping between AD and git committer based on emails.
I feel this is really needed, as I don't like disabling the security check against registered Jenkins users.... We did have in the past a few cases of embarrassing leaked emails from Jenkins because we compile 3rd party applications and committers outside the organization appeared as the culprits in some failed builds. Until Jenkins does proper user mapping based on email we are vulnerable to this issue because we are forced to disable the security feature in the meantime.
I was just hit by the same issue. E-mail should be compared against e-mail field, not processed and compared against some different field. Or at least please give an option to choose the behaviour.
Hopefully this bumps this thread. I am in the exact same spot as jeremfg.
Since this ticket looks like its stuck in limbo, did anyone find any solution to this?
BUMP TOO
we have 6 companies working on the machine.
You wont believe what funny names show up in the commiter list of asynchPeople.
This is ABSOLUTELY not an option for a secure environment.
The aysncList we see there is neither injective and can be used to identify, nor is it surjective and I can be sure that my git server will contain the entry as this is the job of the gitserver which might not keep all the user.name 's used by its users over time.
This is REALLY WRONG!!!
As a workaround I've used the field "Allowed Domains" of the email-ext plugin.
The first time I run into the issue
"Not sending mail to unregistered user abc@xyz.com because your SCM claimed this was associated with a user ID `` which your security realm does not recognize; you may need changes in your SCM plugin."
(see https://docs.cloudbees.com/docs/cloudbees-ci-kb/latest/client-and-managed-masters/not-sending-mail-to-unregistered-user-associated-with-scm)
was all developers had to change their email address to a new domain.
Even after telling them to update the email address in their Jenkins account, it did not really fix the issue for all developers.
After checking the source code https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java
and doing some tests according to the source code, I came to the following results:
Jenkins always creates new Jenkins user accounts nevertheless if "Create new accounts based on author/committer's email?" is checked:
user = getUser(csAuthorEmail, true); } if (user != null && setUserDetails) { user.setFullName(csAuthor);
... or not checked:
user = getUser(emailParts[0], true);
Use case A:
At the beginning the Jenkins server was running with "Create new accounts based on author/committer's email?" false.
The result is that some developers have got 2 Jenkins accounts now:
UserID 1: "firstname.lastname" (auto-created account by GitChangeSet)
UserID 2: "lastname" ("lastname" is in my company the user name for the Jenkins login and matches the LDAP account and is dependent on your company's policy)
I guess this happens when a developer logs into Jenkins after pushing his/her first commit.
Use case B:
Later all developers have updated their email address for UserID 2, but not in UserID 1. Which fixed the issue for some developers,
but not for all because:
user = getUser(csAuthor, false);
is looking for the ID or FullName of all Jenkins accounts that matches the extracted "user.name" of the author commit
(e.g. "Firstname LASTNAME <firstname.lastname@mycompany.com>" -> "user.name" = "Firstname LASTNAME").
and this comparison is case sensitive!
One little typo and the account "does not exist" although it exists and then a new account will be created with "firstname.lastname" (as ID and Full Name)!
You can test it via "Script Console" in Jenkins, e.g. like this:
def u = User.get('lastname', false, Collections.emptyMap()) // my company LDAP ID //def u = User.get('Firstname LASTNAME', false, Collections.emptyMap()) // Full Name of my authorized LDAP Jenkins account (CASE-SENSITIVE!) //def u = User.get('firstname.lastname', false, Collections.emptyMap()) // auto-created account from initial pushed commit return "id = " + u.getId() + ", FullName = " + u.getFullName() + ", no. of authorities = " + u.getAuthorities()?.size()
Lets assume there is a little typo between Jenkins account FullName and author commit
(which is a quite common practice in developers life because "git config user.name" is not always set correctly for all dev-tools and environments) then this line will be used:
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L499
String[] emailParts = csAuthorEmail.split("@"); if (emailParts.length > 0) { try { user = getUser(emailParts[0], true);
And this is for my company (LDAP policy) always the UN-authorized Jenkins User Account!
Improvement B.1)
In my opinion to improve here the functionality of enabling/disabling "auto-create user account" should be implemented.
From a security point of view this ends up in the same situation:
no account -> no email will be send
no authorized account -> no email will be send
Improvement B.2)
Another improvement could be that
user = getUser(csAuthor, false);
is looking for matching Full Names but with case-insensitivity.
Improvement B.3)
Another improvement could be (if auto-creating is enabled):
// check user = getUser(emailParts[0], false); // if not then create user = getUser(emailParts[0], true); // and update the user with the extracted user.name and user.email of the author commit: user.setFullName(csAuthor); setMail(user, csAuthorEmail);
OR in respect of this ticket here instead of creating "firstname.lastname" let's take the extracted author name:
// check and if not then create user = getUser(csAuthor, true); // and update the user with the extracted user.email of the author commit: setMail(user, csAuthorEmail);
Improvement B.4)
If
"Create new accounts based on author/committer's email?" false
"Use existing account with same email if found?" true
then before Improvement suggestion B.3 search for accounts with the same email address.
The code here https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L458 and ff. can be re-used.
Use case C:
Later my company changed the LDAP policy (1-to-n characters of the firstname plus lastname) and now things got really bad.
So I changed the Jenkins server setting to:
"Create new accounts based on author/committer's email?" true
"Use existing account with same email if found?" true
because I read it might fix the issue. But in real life for some developers it doesn't work either.
And the reason is there is a loop in the source code:
for(User existingUser : User.getAll()) { if (csAuthorEmail.equalsIgnoreCase(getMail(existingUser))) { user = existingUser; setUserDetails = false; break; // this line is a real problem } }
and it stops searching as soon as it got the first UserID with the matching email address.
In real life some developers have got 3 Jenkins accounts now:
user.name = "Firstname LASTNAME"
user.email = "firstname.lastname@mycompany.com"
author commit = "Firstname LASTNAME <firstname.lastname@mycompany.com>"
LDAP/AD = "lastname"
UserID 1: "firstname.lastname" (from use case A or use case B)
UserID 2: "firstname.lastname@mycompany.com" (from use case B)
UserID 3: "lastname" (authorized by LDAP)
Well, UserID 1 and 2 are both smaller than UserID 3 ("firstname.lastname" < ""firstname.lastname@mycompany.com"" < "lastname")
and that's why for some users the UN-authorized UserID 1 or 2 are always taken and not the authorized account UserID 3.
You can test it via "Script Console" in Jenkins, e.g. like this:
def u = [] for (User existingUser : User.getAll()) { if ('firstname.lastname@mycompany.com'.equalsIgnoreCase(existingUser.getProperty(hudson.tasks.Mailer.UserProperty.class).getExplicitlyConfiguredAddress())) { u += existingUser.getId() + " : " + existingUser.getFullName() + " (" + existingUser.getAuthorities().size() + ")" //break // this line is a real problem } } return u
Improvement C.1)
So a quick bug fix (see line 460) could look like this:
for(User existingUser : User.getAll()) { if (csAuthorEmail.equalsIgnoreCase(getMail(existingUser)) && existingUser.getAuthorities().size() > 0) { // line 460 user = existingUser; setUserDetails = false; break; } }
Summary:
As long as the source code is not improved and you don't want to check "Allow sending to unregistered users" then the only workaround is:
Either my company adapts the LDAP policy to the Jenkins logic:
firstname.lastname@mycompany.com
or
firstname.lastname
OR
to disable "Create new accounts based on author/committer's email?" and tell a developers:
log into Jenkins and make sure that:
git user.name = jenkins.fullname (CASE-SENSITIVE!)
git user.email = jenkins.email
UPDATE:
My own Improvement suggestion B.3 will also not work and the reason is:
def u = User.get('Firstname LASTNAME', false, Collections.emptyMap())
always returns the first UserID if all 2 or 3 Jenkins accounts have the same Full Name 'Firstname LASTNAME':
UserID 1: "firstname.lastname" (fullName "Firstname LASTNAME", I changed it afterwards as admin just for testing)
UserID 2: "firstname.lastname@mycompany.com" (fullName "Firstname LASTNAME" extracted user.name and set by auto-create)
UserID 3: "lastname" (fullName "Firstname LASTNAME" set by developer)
So auto-creating a new user and extracting the user.name and updating it as FullName
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L471
is also not good if you want to use:
user = getUser(csAuthor, false);
later (after disabling "Create new accounts based on author/committer's email").
So Improvement suggestion B.1 enabling/disabling "auto-create user account" and cleaning-up UN-authorized Jenkins accounts later seems to me the only working solution here, unless deeper Jenkins core and/or LDAP plugin improvements will be provided here by experts.
We recently tripped over this - to me, the code should look for a user that is using the email address of the culprit rather than clumsily trying to guess at a username to match with - in our case, we may have some meta data pumped into the Full names by the directory management team.
I'm curious what would be the knock on effects of having the culprit code use hudson.tasks.Mailer.UserProperty(csAuthorEmail) and searching for a match among all users.
Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/hudson/plugins/git/GitChangeSet.java
http://jenkins-ci.org/commit/git-plugin/3607d2ec90f69edcf8cedfcb358ce19a980b8f1a
Log:
[FIXED JENKINS-9016] If no Jenkins user is found for the commit's user.name value, use the username section of the email address instead.