Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53266

Legacy token for user "unknown" keeps reappearing

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core
    • None
    • Jenkins versions 2.130 through 2.140 alpine docker image.

      Ever since the API token change introduced by JENKINS-32776, a legacy token is automagically generated on our install for the nonexistent user "unknown".

      Legacy tokens have been disabled since updating to 2.130.

      After manually revoking the token, it usually takes a few hours for it to magically reappear and then causes the red administrative monitor counter to (re-)appear in the toolbar.

      Though I can revoke the token, I am unable to change it via the user admin page Change API Token button.

        1. legacy-setting.png
          legacy-setting.png
          22 kB
        2. legacy-warn.png
          legacy-warn.png
          20 kB
        3. plugins.txt
          5 kB
        4. plugins-merged.lieverdink.kolinek.froque.txt
          1 kB
        5. plugins-merged.txt
          1 kB
        6. unknown-user.png
          unknown-user.png
          71 kB

          [JENKINS-53266] Legacy token for user "unknown" keeps reappearing

          Thank you cafuego for the quick answer, I will try to reproduce the case as soon I have time and keep you informed.

          Wadeck Follonier added a comment - Thank you cafuego for the quick answer, I will try to reproduce the case as soon I have time and keep you informed.

          I have the same issue. The "unknown" token reappears after every restart of Jenkins. I've created the list of plugins that are present on my instance AND in list provided by cafuego: plugins-merged.txt. Hopefully this will help to narrow the search.

           

          Peter Kolínek added a comment - I have the same issue. The "unknown" token reappears after every restart of Jenkins. I've created the list of plugins that are present on my instance AND in list provided by cafuego : plugins-merged.txt . Hopefully this will help to narrow the search.  

          Emil Styrke added a comment -

          wfollonier I have this issue too. I have all the plugins from the "merged" set except "Build Pipeline Plugin", "Build Timeout", "Email Extension Plugin", "Environment Injector Plugin" and "Windows Slaves Plugin".

          Emil Styrke added a comment - wfollonier I have this issue too. I have all the plugins from the "merged" set except "Build Pipeline Plugin", "Build Timeout", "Email Extension Plugin", "Environment Injector Plugin" and "Windows Slaves Plugin".

          Filipe Roque added a comment -

          I also have this problem. Two users that after revoking legacy tokens, keep coming back.

          I have attached plugins-merged.lieverdink.kolinek.froque.txt with common plugins

          Filipe Roque added a comment - I also have this problem. Two users that after revoking legacy tokens, keep coming back. I have attached plugins-merged.lieverdink.kolinek.froque.txt  with common plugins

          Ken Rachynski added a comment -

          I can suggest three more removals from froque's list. I do not have Build Pipeline Plugin, Dashboard View, or Pipeline Graph Analysis Plugin on the server where I'm seeing this behaviour.

          I set up a Docker instance and added most of my production plugins in by hand and have not been able to reproduce this behaviour yet. I say most because I have a NCover plugin in production that doesn't seem to exist any more. As I haven't been able to reproduce this empty token issue, I'm beginning to suspect that this is due to an upgrade somewhere along the lines.

          Ken Rachynski added a comment - I can suggest three more removals from froque 's list. I do not have Build Pipeline Plugin, Dashboard View, or Pipeline Graph Analysis Plugin on the server where I'm seeing this behaviour. I set up a Docker instance and added most of my production plugins in by hand and have not been able to reproduce this behaviour yet. I say most because I have a NCover plugin in production that doesn't seem to exist any more. As I haven't been able to reproduce this empty token issue, I'm beginning to suspect that this is due to an upgrade somewhere along the lines.

          Ken Rachynski added a comment - - edited

          Since I suspect this is due to a plugin upgrade at some point, I decided to do some digging. It looks like revoking legacy tokens for some users isn't actually revoking them. I have one unknown user on my system that shows up every time I restart Jenkins. I've been revoking the token each time it comes up without luck.

          Logging into my Jenkins host computer, I looked in the users folder for my unknown user. users.xml told me what directory it was in and the config.xml confirmed the legacy token.

          <jenkins.security.ApiTokenProperty>
              <apiToken>tokenhash</apiToken>
          </jenkins.security.ApiTokenProperty>

          The new format looks more like

          <jenkins.security.ApiTokenProperty>
            <tokenStore>
              <tokenList>
                <jenkins.security.apitoken.ApiTokenStore_-HashedToken>
                  <uuid>uuid</uuid>
                  <name>mytoken</name>
                  <creationDate>2019-11-28 18:37:11.655 UTC</creationDate>
                  <value>
                    <version>11</version>
                    <hash>tokenhash</hash>
                  </value>
                </jenkins.security.apitoken.ApiTokenStore_-HashedToken>
              </tokenList>
            </tokenStore>
          </jenkins.security.ApiTokenProperty>

          Since I was looking to revoke the token outright, I just deleted the <apiToken> line in config.xml and restarted Jenkins.

           

          Ken Rachynski added a comment - - edited Since I suspect this is due to a plugin upgrade at some point, I decided to do some digging. It looks like revoking legacy tokens for some users isn't actually revoking them. I have one unknown user on my system that shows up every time I restart Jenkins. I've been revoking the token each time it comes up without luck. Logging into my Jenkins host computer, I looked in the users folder for my unknown user. users.xml told me what directory it was in and the config.xml confirmed the legacy token. <jenkins.security.ApiTokenProperty>     <apiToken>tokenhash</apiToken> </jenkins.security.ApiTokenProperty> The new format looks more like <jenkins.security.ApiTokenProperty>   <tokenStore>     <tokenList>       <jenkins.security.apitoken.ApiTokenStore_-HashedToken>         <uuid>uuid</uuid>         <name>mytoken</name>         <creationDate>2019-11-28 18:37:11.655 UTC</creationDate>         <value>           <version>11</version>           <hash>tokenhash</hash>         </value>       </jenkins.security.apitoken.ApiTokenStore_-HashedToken>     </tokenList>   </tokenStore> </jenkins.security.ApiTokenProperty> Since I was looking to revoke the token outright, I just deleted the <apiToken> line in config.xml and restarted Jenkins.  

          Ken Rachynski added a comment -

          As near as I can tell right now, the Revoke selected token(s) button calls this method: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/security/apitoken/LegacyApiTokenAdministrativeMonitor.java#L159-L185

          But none of the logging present there seems to be hitting my Jenkins logs.

          Ken Rachynski added a comment - As near as I can tell right now, the Revoke selected token(s) button calls this method: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/security/apitoken/LegacyApiTokenAdministrativeMonitor.java#L159-L185 But none of the logging present there seems to be hitting my Jenkins logs.

          krachynski Yep, confirmed. I checked the users.xml file and also found an "unknown" entry in there pointing at an old format token in users/foo/config.xml. I've deleted said user, in theory that'll mean the warning doesn't come back after a restart.

          I am pretty sure that entry in list of users is courtesy of GitHub integration; Jenkins tries to enumerate people its finds in git commits, whether they have actual Jenkins logins or not. The "unknown" user in question has an email address that does match a former staff member, but it's not one that we ever used in LDAP.

          Peter Lieverdink added a comment - krachynski Yep, confirmed. I checked the users.xml file and also found an "unknown" entry in there pointing at an old format token in users/foo/config.xml. I've deleted said user, in theory that'll mean the warning doesn't come back after a restart. I am pretty sure that entry in list of users is courtesy of GitHub integration; Jenkins tries to enumerate people its finds in git commits, whether they have actual Jenkins logins or not. The "unknown" user in question has an email address that does match a former staff member, but it's not one that we ever used in LDAP.

          Ken Rachynski added a comment -

          Oh good catch. I have jglick as one of my users and I recall that's because I built his sample pipeline job from github directly. The unknown user in my case is one of our current staff members, but it's likely that record was added before I switched to Active Directory as my source.

           

          Ken Rachynski added a comment - Oh good catch. I have jglick as one of my users and I recall that's because I built his sample pipeline job from github directly. The unknown user in my case is one of our current staff members, but it's likely that record was added before I switched to Active Directory as my source.  

          João Pinto added a comment -

          I've also been affected by this. Changing a user's name from "unknown" to something else allows the legacy token to be properly revoked.
          The email of the user in question seems to be a default one generated by git (username@hostname) so it might indeed be one of the Git integrations creating a user from commits without a Git author configured.

          João Pinto added a comment - I've also been affected by this. Changing a user's name from "unknown" to something else allows the legacy token to be properly revoked. The email of the user in question seems to be a default one generated by git (username@hostname) so it might indeed be one of the Git integrations creating a user from commits without a Git author configured.

            wfollonier Wadeck Follonier
            cafuego Peter Lieverdink
            Votes:
            8 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: