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

Input submitter parameter should use the current IdStrategy to match against current user

    XMLWordPrintable

Details

    • pipeline-input-step 2.9

    Description

      Problem statement

      Depending on the current SecurityRealm, the input step will refuse or accept submitters depending on the case sensitivity settings.

      Despite there is probably some logic to be improved too on various SecurityRealm implementations, I think there is still an improvement to be done on the Pipeline-input side. Bonus point: it's also likely much simpler than addressing all SecurityRealms implems out there.

      Example:

      input message: "blah", submitter: "SomeUser"
      

      Even if the strategy is the default CASE_INSENSITIVE one, the configuration above will reject a user logged in as someuser.

      Expected behavior

      The SecurityRealm core class already defines the so-called IdStrategy which contain various methods for comparing and sorting user ids. I think the input step logic around validating the current user against the submitters list should be using this implementation.

      References:

      Attachments

        Issue Links

          Activity

            batmat Baptiste Mathus created issue -
            batmat Baptiste Mathus made changes -
            Field Original Value New Value
            Description h3. Problem statement

            Depending on the current SecurityRealm, the input step will refuse of accept submitters with or without taking the case sensitivity in account.

            Despite there is some logic probably to be improved too on various SecurityRealm implementations, I think there is still a bug, or at least a possible improvement, on the Pipeline-input side.


            Example:


            {code:groovy}
            input message: "blah", submitter: "SomeUser"
            {code}




            h3. Expected behavior

            The SecurityRealm core class already defines the so-called IdStrategy which contain various methods for comparing and sorting user ids. I think the input step logic around validating the current user against the submitters list should be using this implementation.

            h3. Problem statement

            Depending on the current SecurityRealm, the input step will refuse or accept submitters depending on the case sensitivity settings.

            Despite there is probably some logic to be improved too on various SecurityRealm implementations, I think there is still an improvement to be done on the Pipeline-input side. Bonus point: it's also likely much simpler than addressing all SecurityRealms implems out there.

            Example:
            {code}
            input message: "blah", submitter: "SomeUser"
            {code}

            Even if the strategy is the default [CASE_INSENSITIVE|https://github.com/jenkinsci/jenkins/blob/486b1566eef41443a34b7b1ec025524c7fecfd56/core/src/main/java/jenkins/model/IdStrategy.java#L58] one, the configuration above will reject a user logged in as {{someuser}}.

            h3. Expected behavior

            The SecurityRealm core class already defines the so-called IdStrategy which contain various methods for comparing and sorting user ids. I think the input step logic around validating the current user against the submitters list should be using this implementation.

            References:
            * https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/model/IdStrategy.java
            * https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/security/SecurityRealm.java
            * https://github.com/jenkinsci/jenkins/blob/486b1566eef41443a34b7b1ec025524c7fecfd56/core/src/main/java/jenkins/model/IdStrategy.java#L58
            batmat Baptiste Mathus made changes -
            Description h3. Problem statement

            Depending on the current SecurityRealm, the input step will refuse or accept submitters depending on the case sensitivity settings.

            Despite there is probably some logic to be improved too on various SecurityRealm implementations, I think there is still an improvement to be done on the Pipeline-input side. Bonus point: it's also likely much simpler than addressing all SecurityRealms implems out there.

            Example:
            {code}
            input message: "blah", submitter: "SomeUser"
            {code}

            Even if the strategy is the default [CASE_INSENSITIVE|https://github.com/jenkinsci/jenkins/blob/486b1566eef41443a34b7b1ec025524c7fecfd56/core/src/main/java/jenkins/model/IdStrategy.java#L58] one, the configuration above will reject a user logged in as {{someuser}}.

            h3. Expected behavior

            The SecurityRealm core class already defines the so-called IdStrategy which contain various methods for comparing and sorting user ids. I think the input step logic around validating the current user against the submitters list should be using this implementation.

            References:
            * https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/model/IdStrategy.java
            * https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/security/SecurityRealm.java
            * https://github.com/jenkinsci/jenkins/blob/486b1566eef41443a34b7b1ec025524c7fecfd56/core/src/main/java/jenkins/model/IdStrategy.java#L58
            h3. Problem statement

            Depending on the current SecurityRealm, the input step will refuse or accept submitters depending on the case sensitivity settings.

            Despite there is probably some logic to be improved too on various SecurityRealm implementations, I think there is still an improvement to be done on the Pipeline-input side. Bonus point: it's also likely much simpler than addressing all SecurityRealms implems out there.

            Example:
            {code}
            input message: "blah", submitter: "SomeUser"
            {code}

            Even if the strategy is the default [CASE_INSENSITIVE|https://github.com/jenkinsci/jenkins/blob/486b1566eef41443a34b7b1ec025524c7fecfd56/core/src/main/java/jenkins/model/IdStrategy.java#L58] one, the configuration above will reject a user logged in as {{someuser}}.

            h3. Expected behavior

            The SecurityRealm core class already defines the so-called IdStrategy which contain various methods for comparing and sorting user ids. I think the input step logic around validating the current user against the submitters list should be using this implementation.

            h3. References:
            * https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/jenkins/model/IdStrategy.java
            * https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/security/SecurityRealm.java
            * https://github.com/jenkinsci/jenkins/blob/486b1566eef41443a34b7b1ec025524c7fecfd56/core/src/main/java/jenkins/model/IdStrategy.java#L58
            batmat Baptiste Mathus made changes -
            Assignee Baptiste Mathus [ batmat ]
            batmat Baptiste Mathus made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            batmat Baptiste Mathus made changes -
            Remote Link This issue links to "PR (Web Link)" [ 22103 ]
            batmat Baptiste Mathus made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            batmat Baptiste Mathus made changes -
            Released As (toward) 2.9
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            batmat Baptiste Mathus made changes -
            Status Resolved [ 5 ] Fixed but Unreleased [ 10203 ]
            batmat Baptiste Mathus made changes -
            Released As (toward) 2.9 (towards) 2.9
            dnusbaum Devin Nusbaum made changes -
            Released As (towards) 2.9 pipeline-input-step 2.9
            Status Fixed but Unreleased [ 10203 ] Resolved [ 5 ]

            People

              batmat Baptiste Mathus
              batmat Baptiste Mathus
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: