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

[chris+jenkins@chriskilding.com (JIRA)]

Chris Kilding created an issue

Jenkins / JENKINS-59626 Global configuration page blocks may try to load credentials before credentials providers are ready Issue Type: Bug Assignee: Unassigned Components: core Created: 2019-10-02 15:02 Labels: configuration credentials Priority: Major Reporter: Chris Kilding 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.) Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[dbeck@cloudbees.com (JIRA)]

Daniel Beck updated an issue

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

Change By: Daniel Beck Component/s: credentials-plugin Component/s: core

Add Comment

[dbeck@cloudbees.com (JIRA)]

Daniel Beck commented on JENKINS-59626

Re: Global configuration page blocks may try to load credentials before credentials providers are ready 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?

Add Comment

[chris+jenkins@chriskilding.com (JIRA)]

Chris Kilding commented on JENKINS-59626

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

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?

Add Comment

[chris+jenkins@chriskilding.com (JIRA)]

Chris Kilding commented on JENKINS-59626

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

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.

Add Comment