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

Global configuration page blocks may try to load credentials before credentials providers are ready

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      The Jenkins global configuration (/configure) page currently suffers from a chicken-and-egg load order problem between plugins that consume credentials (e.g. Docker plugin) and plugins that provide credentials (e.g. AWS Secrets Manager provider).

      Preconditions

      • The configuration block for the consuming plugin, and the configuration block for the providing plugin, are displayed at the same time.
      • The providing plugin has not been configured yet.
      • The providing plugin is a remote provider, and as such is contractually bound to throw an unchecked exception when it is uninitialised or otherwise cannot contact its backing store.

      Bug

      When the uninitialised remote provider is asked to provide credentials, the exception it throws will crash the /configure page (or part of it).

      Effects

      • Jenkins users will see a (partially) broken /configure page. (But if they can use Configuration As Code, they can get round this.)
      • Plugin integration tests exercising the /configure page will break. (HtmlUnit and the Ajax controller will fail when they detect the page has crashed. There is no workaround for this.)

        Attachments

          Issue Links

            Activity

            chriskilding Chris Kilding created issue -
            Hide
            danielbeck Daniel Beck added a comment -

            Interesting. I checked the Credentials Plugin docs and it says:

            The {{CredentialsProvider.getCredentialIds(…​)}} methods are used to list credentials for drop-down list population, so these methods should use a live request with a fall-back to the cache where the live request takes too long.

            This would indicate the fallback isn't to throw, but to return an empty list?

            Show
            danielbeck Daniel Beck added a comment - Interesting. I checked the Credentials Plugin docs and it says: The {{CredentialsProvider.getCredentialIds(…​)}} methods are used to list credentials for drop-down list population, so these methods should use a live request with a fall-back to the cache where the live request takes too long. This would indicate the fallback isn't to throw, but to return an empty list?
            danielbeck Daniel Beck made changes -
            Field Original Value New Value
            Component/s credentials-plugin [ 16523 ]
            Component/s core [ 15593 ]
            Hide
            chriskilding Chris Kilding added a comment -

            Some observations about returning an empty list:

             

            • The user would not easily be able to know why they saw an empty list (without reading the Jenkins logs): was it because there were no credentials in that store, or was it because access was not configured yet?
            • Depending on where the error fallback empty list is returned in the code, it might get cached by the provider for the cache duration. Is this something we want to happen?
            Show
            chriskilding Chris Kilding added a comment - Some observations about returning an empty list:   The user would not easily be able to know why they saw an empty list (without reading the Jenkins logs): was it because there were no credentials in that store, or was it because access was not configured yet? Depending on where the error fallback empty list is returned in the code, it might get cached by the provider for the cache duration. Is this something we want to happen?
            chriskilding Chris Kilding made changes -
            Link This issue relates to JENKINS-60652 [ JENKINS-60652 ]
            Hide
            chriskilding Chris Kilding added a comment -

            The fallback was to return a non-cached empty list. (Emphasis on the non-cached bit - to avoid an error blocking the plugin from trying again in the next N minutes.) I implemented this in my provider and the credentials UI views no longer break when there is service degradation behind the scenes.

            However the user still does not know that there was a communication error with the backing store, unless they look in the Jenkins logs.

            Show
            chriskilding Chris Kilding added a comment - The fallback was to return a non-cached empty list. (Emphasis on the non-cached bit - to avoid an error blocking the plugin from trying again in the next N minutes.) I implemented this in my provider and the credentials UI views no longer break when there is service degradation behind the scenes. However the user still does not know that there was a communication error with the backing store, unless they look in the Jenkins logs.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              chriskilding Chris Kilding
              Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: