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

non-github accounts can't be used via jenkins-cli or REST APIs

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Won't Fix
    • github-oauth-plugin
    • None
    • github-oauth-plugin v0.26

    Description

      We use scripts to talk to Jenkins to administrate it.   The scripts use a non-GitHub account (using the built-in User store in Jenkins).  An example of this is the Jenkins Cookbook.

      These scripts broke with github-oauth-plugin v0.26 because these users don't have GitHub accounts.

      I know you just fixed all this, sag47 and I really appreciate your hard work on it.

      I think what I would expect is that if someone used an SSH key or the API token that it falls back to the old behavior of not being in the github organizations.

      I realize this is a little confusing for users; I can't think of any alternate ways to allow both GitHub users and non-GitHub users to work together.

      Attachments

        Issue Links

          Activity

            docwhat Christian Höltje added a comment - - edited

            Based on jglick's comment on JENKINS-22346 I suspect this isn't a bug, but rather a feature.

            The main issue is that former versions of Jenkins permitted login via CLI for a user defined in Jenkins configuration with an SSH public key but not present in the actual SecurityRealm, and this is no longer permitted.

            docwhat Christian Höltje added a comment - - edited Based on jglick 's comment on JENKINS-22346  I suspect this isn't a bug, but rather a feature. The main issue is that former versions of Jenkins permitted login via CLI for a user defined in Jenkins configuration with an SSH public key but not present in the actual SecurityRealm , and this is no longer permitted.
            jglick Jesse Glick added a comment -

            Yes. There is a system property to revert to the old behavior, which is considered a security hole.

            jglick Jesse Glick added a comment - Yes. There is a system property to revert to the old behavior, which is considered a security hole.

            Is there documentation for that property? I didn't see it on the security page(s) in the wiki.

            I don't think it is what I want, but it'd be interesting to know.

            docwhat Christian Höltje added a comment - Is there documentation for that property? I didn't see it on the security page(s) in the wiki. I don't think it is what I want, but it'd be interesting to know.

            It's working as designed which seems to be correct; closing this issue.

            docwhat Christian Höltje added a comment - It's working as designed which seems to be correct; closing this issue.
            sag47 Sam Gleske added a comment -

            It's possible this was fixed by JENKINS-43822.

            sag47 Sam Gleske added a comment - It's possible this was fixed by JENKINS-43822 .

            People

              sag47 Sam Gleske
              docwhat Christian Höltje
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: