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

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

      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.)

          [JENKINS-59626] Global configuration page blocks may try to load credentials before credentials providers are ready

          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?

          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?

          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?

          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?

          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.

          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.

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

              Created:
              Updated: