-
Bug
-
Resolution: Not A Defect
-
Major
-
None
-
Using plugin version 1.3.0
Using a trivial Pipeline project, we are seeing differing credential behavior with `Run As Specific User` vs `Run As User who Triggered Build` using User Private credentials (https://<server>/user/<user>/credentials/store/user/domain/_/).
Here is the code for the Pipeline. This is configured inline in the Pipeline Job.
// code placeholder node { withCredentials([usernameColonPassword(credentialsId: 'user-private-credential', variable: 'SOME_VALUE')]) { sh('echo ${SOME_VALUE} | shasum') } }
In the Pipeline above `user-private-credential` is defined for the user executing the script.
—
When the Authorization mode is set to "Run As Specific Build", the script is able to successfully retrieve the user's credentials.
If the Authorization mode is set to "Run As User who Triggered Build", then the pipeline is unable to retrieve the credentials.
—
The desired behavior is to be able to retrieve the credentials in both cases.
- is related to
-
-
- Open
-
-
-
- Closed
-
[JENKINS-55052] Different behavior accessing user credentials using RunAs Specific vs. Triggered User
Michael Ahern
created issue -
ikedam
made changes -
| Component/s | New: credentials-plugin [ 16523 ] |
ikedam
made changes -
| Link |
New:
This issue is related to |
ikedam
made changes -
| Assignee | Original: ikedam [ ikedam ] | New: Michael Ahern [ iamahern ] |
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Fixed but Unreleased [ 10203 ] |
Michael Ahern
made changes -
| Status | Original: Fixed but Unreleased [ 10203 ] | New: Reopened [ 4 ] |
Apologies, so my use case is slightly different than JENKINS 24750. In that case it regards propagation of Credential Parameter values along a call chain:
withCredentials([usernameColonPassword(credentialsId: '${CREDENTIAL_PARAM}', variable: 'SOME_VALUE')])
In my case, I am simply attempting to access the User's credential directly by id:
withCredentials([usernameColonPassword(credentialsId: 'user-private-credential', variable: 'SOME_VALUE')])
After a bit of debugging, I discovered that the issue is that "Queue.WaitingItem.getCause()" is always empty (i.e. the "UserIdCause" is not propagated correctly):
if (item instanceof Queue.WaitingItem && item.getCauses().isEmpty()) { /* Always true for if (item instanceof Queue.WaitingItem) */ }
ikedam - is this by design or a defect in the system?
Either way, I extended the plugin with an optional (false by default) checkbox which provides a workaround. Will follow up on a Pull Request with a request for assistance to either track down the underlying defect (if this behavior is not by design) or for pointers as to how to implement a suitable unit test to get the patch accepted.
Michael Ahern
added a comment - - edited Apologies, so my use case is slightly different than JENKINS 24750. In that case it regards propagation of Credential Parameter values along a call chain:
withCredentials( [usernameColonPassword(credentialsId: '${CREDENTIAL_PARAM}', variable: 'SOME_VALUE')] )
In my case, I am simply attempting to access the User's credential directly by id:
withCredentials( [usernameColonPassword(credentialsId: 'user-private-credential', variable: 'SOME_VALUE')] )
After a bit of debugging, I discovered that the issue is that "Queue.WaitingItem.getCause()" is always empty (i.e. the "UserIdCause" is not propagated correctly):
if (item instanceof Queue.WaitingItem && item.getCauses().isEmpty()) { /* Always true for if (item instanceof Queue.WaitingItem) */ }
ikedam - is this by design or a defect in the system?
Either way, I extended the plugin with an optional (false by default) checkbox which provides a workaround. Will follow up on a Pull Request with a request for assistance to either track down the underlying defect (if this behavior is not by design) or for pointers as to how to implement a suitable unit test to get the patch accepted.
Michael Ahern
added a comment - Michael Ahern
added a comment - PR Link:
https://github.com/jenkinsci/authorize-project-plugin/pull/32 Michael Ahern
made changes -
| Link | New: This issue is related to JENKINS-44772 [ JENKINS-44772 ] |
ikedam
added a comment - Sorry for my absence.
It sounds strange both that `WaitingItem` is passed and that `Cause` is not set for `WaitingItem`.
Both sounds issues not of authorize-project, but rather of Jenkins core (or may be credentials-plugin).
All that authorize-project can do is to decide the authentication from information of passed items.
I still think that this is essentially same to JENKINS-24750, as the point of JENKINS-24750 is not the propagation, but that credentials-plugin decides authentication by attributes not of builds but of jobs.
The workaround isn’t a good way as you described in that request, and I expect you have deeper look on how `WaitingItem` is passed, and why that workaround works.
ikedam
added a comment - Sorry for my absence.
It sounds strange both that `WaitingItem` is passed and that `Cause` is not set for `WaitingItem`.
Both sounds issues not of authorize-project, but rather of Jenkins core (or may be credentials-plugin).
All that authorize-project can do is to decide the authentication from information of passed items.
I still think that this is essentially same to JENKINS-24750 , as the point of JENKINS-24750 is not the propagation, but that credentials-plugin decides authentication by attributes not of builds but of jobs.
The workaround isn’t a good way as you described in that request, and I expect you have deeper look on how `WaitingItem` is passed, and why that workaround works.
That’s a known issue, and a limitation for the security reason of credentials-plugin.
Please have a look on
JENKINS-24750for details.