[JIRA] (JENKINS-61785) REST API requires Job/Build permission
Title: Message Title Juan Pablo Santos Rodríguez commented on JENKINS-61785 Re: REST API requires Job/Build permission Hi, we were able to locate what's happening, seems that efectively there's a bug introduced in latests LTS / role-strategy-plugin versions: The user id we were using on our API calls was "INETIC" (uppercased, as it is how it is set up on the active directory); this could be seen while debugging curl's request headers: "* Server auth using Basic with user 'INETIC'". Response headers told something a bit different, though: "< X-You-Are-Authenticated-As: inetic" (note user id is lowercased here). The "Manage Roles" screen assigns roles to INETIC no matter how you introduce the ID. Most probably, the user id is being fetched from the AD, which makes sense. From within the API call, being authenticated as inetic, there are no roles assigned to it, as they are assigned to INETIC. Seems that this lowercasing wasn't happening before. We've changed the API user (with its associated token) to another with a lowercased user id and our problems are gone. This wasn't happening on our previous Jenkins instance (2.204.2 LTS with role-strategy-plugin 2.14, IIRC). The issue seems to happen with newer Jenkins LTS instances + role-strategy plugin 2.15 and 2.16, don't know specifically where the bug / regression is lying.. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
[JIRA] (JENKINS-61785) REST API requires Job/Build permission
Title: Message Title Juan Pablo Santos Rodríguez updated an issue Jenkins / JENKINS-61785 REST API requires Job/Build permission Change By: Juan Pablo Santos Rodríguez Summary: REST API requires Task Job /Build permission Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.205624.1585839242000.5816.1585909740180%40Atlassian.JIRA.
[JIRA] (JENKINS-61785) REST API requires Task/Build permission
Title: Message Title
Juan Pablo Santos Rodríguez updated an issue
Jenkins / JENKINS-61785
REST API requires Task/Build permission
Change By:
Juan Pablo Santos Rodríguez
After upgrading to Jenkins LTS 2.222.1 + role-strategy-plugin 2.16, REST API calls have stopped working. On the Log we can see {code}2020-04-02 14:42:46.468+ [id=20318] INFO o.e.j.s.h.ContextHandler$Context#log: While serving http://XXX/jenkins/job/YY-pipeline/buildWithParameters: hudson.security.AccessDeniedException2: inetic is missing the Job/Build permission{code}which is exactly what we get through the REST APIinetic has Admin permissions granted to a role, set throuch role-strategy-plugin and is able to execute any jobs through the UI.We're using user+token for auth, which should not need Jenkins-Crumb header. Nevertheless, we've also tried user+password+crumb and user+token+crumb and we get the same results. We've also tried setting {{hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION}} to either {{true}} or {{false}}, but again, it makes no difference.May be the security hardening done on 2.222.1 / 2.204.6 affects the role-strategy-plugin?Only workaround found so far is to set global Read + Build permissions, however that allows every user to execute everything without being logged which is not so funny.EDIT: forgot to add, $JENKINS/whoAmI for user yields:{code}Name: INETICIsAuthenticated?: trueAuthorities: * "authenticated"{code}
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-s
[JIRA] (JENKINS-61785) REST API requires Task/Build permission
Title: Message Title
Juan Pablo Santos Rodríguez updated an issue
Jenkins / JENKINS-61785
REST API requires Task/Build permission
Change By:
Juan Pablo Santos Rodríguez
After upgrading to Jenkins LTS 2.222.1 + role-strategy-plugin 2.16, REST API calls have stopped working. On the Log we can see {code}2020-04-02 14:42:46.468+ [id=20318] INFO o.e.j.s.h.ContextHandler$Context#log: While serving http://XXX/jenkins/job/YY-pipeline/buildWithParameters: hudson.security.AccessDeniedException2: inetic is missing the Job/Build permission{code}which is exactly what we get through the REST APIinetic has Admin permissions set throuch role-strategy-plugin and is able to execute any jobs through the UI.We're using user+token for auth, which should not need Jenkins-Crumb header. Nevertheless, we've also tried user+password+crumb and user+token+crumb and we get the same results. We've also tried setting {{hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION}} to either {{true}} or {{false}}, but again, it makes no difference.May be the security hardening done on 2.222.1 / 2.204.6 affects the role-strategy-plugin?Only workaround found so far is to set global Read + Build permissions, however that allows every user to execute everything without being logged which is not so funny. EDIT: forgot to add, $JENKINS/whoAmI for user yields:{code}Name: INETICIsAuthenticated?: trueAuthorities: * "authenticated"{code}
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
[JIRA] (JENKINS-61785) REST API requires Task/Build permission
Title: Message Title Juan Pablo Santos Rodríguez created an issue Jenkins / JENKINS-61785 REST API requires Task/Build permission Issue Type: Bug Assignee: Oleg Nenashev Components: role-strategy-plugin Created: 2020-04-02 14:54 Environment: Jenkins LTS 2.222.1 role-strategy-plugin 2.16 Priority: Major Reporter: Juan Pablo Santos Rodríguez After upgrading to Jenkins LTS 2.222.1 + role-strategy-plugin 2.16, REST API calls have stopped working. On the Log we can see 2020-04-02 14:42:46.468+ [id=20318] INFO o.e.j.s.h.ContextHandler$Context#log: While serving http://XXX/jenkins/job/YY-pipeline/buildWithParameters: hudson.security.AccessDeniedException2: inetic is missing the Job/Build permission which is exactly what we get through the REST API inetic has Admin permissions set throuch role-strategy-plugin and is able to execute any jobs through the UI. We're using user+token for auth, which should not need Jenkins-Crumb header. Nevertheless, we've also tried user+password+crumb and user+token+crumb and we get the same results. We've also tried setting hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION to either true or false, but again, it makes no difference. May be the security hardening done on 2.222.1 / 2.204.6 affects the role-strategy-plugin? Only workaround found so far is to set global Read + Build permissions, however that allows every user to execute everything without being logged which is not so funny.
[JIRA] (JENKINS-36780) EZ-Templates support Pipeline plugin
Title: Message Title Juan Pablo Santos Rodríguez commented on JENKINS-36780 Re: EZ-Templates support Pipeline plugin sent PR https://github.com/jenkinsci/ez-templates-plugin/pull/3 to add support for pipelines Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38695) Adding promotions needs to exclude .svn directories
Title: Message Title Juan Pablo Santos Rodríguez commented on JENKINS-38695 Re: Adding promotions needs to exclude .svn directories Hi, well it was working for us :O). In any case we've tried with current trunk and it also works fine best regards, Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38695) Adding promotions needs to exclude .svn directories
Title: Message Title Juan Pablo Santos Rodríguez closed an issue as Fixed adding a comment makes sense, thanks for merging Jenkins / JENKINS-38695 Adding promotions needs to exclude .svn directories Change By: Juan Pablo Santos Rodríguez Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38695) Add a sanity check when adding promotions
Title: Message Title juan pablo santos commented on JENKINS-38695 Re: Add a sanity check when adding promotions PR: https://github.com/jenkinsci/ez-templates-plugin/pull/2 thanks! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38695) Add a sanity check when adding promotions
Title: Message Title juan pablo santos created an issue Jenkins / JENKINS-38695 Add a sanity check when adding promotions Issue Type: Bug Assignee: Joel Johnson Components: ez-templates-plugin Created: 2016/Oct/04 12:28 PM Priority: Major Reporter: juan pablo santos We've recently began to keep our Jenkins configuration on SVN. This causes an uncheked exception when adding the promotions, because subversion adds a .svn directory inside promotions and PromotedBuildsTemplateUtils asks for a config.xml file inside every folder on promotions so, when it reaches .svn, the FileInputStream throws a FileNotFoundException which is propagated later on. Small fix in the form of a PR following shortly. (btw, feel free to edit the JIRA as needed, was a bit unsure about cataloging the issue as a bug or as an improvement and also with priority..) Add Comment
[JIRA] (JENKINS-36749) Saves on templates don't propagate to implementing jobs
Title: Message Title juan pablo santos created an issue Jenkins / JENKINS-36749 Saves on templates don't propagate to implementing jobs Issue Type: Bug Assignee: Joel Johnson Components: ez-templates-plugin Created: 2016/Jul/18 8:49 AM Priority: Major Reporter: juan pablo santos Hi, after migrating from jenkins 1.642 to 2.13, with ez-templates 1.1.2 to 1.2.0, saving a template doesn't propagate the changes to the implementing jobs. Instead this exception is thrown on the logs (after a logger for com.joelj.jenkins.eztemplates is set up): 18-Jul-2016 09:31:48.381 WARNING [Handling POST /jenkins/JOB_VIEW/MY_JOB/configSubmit from 10.4.11.43 : http-nio-8080-exec-6] hudson.model.listeners.ItemListener.forAll failed to send event to listener of class com.joelj.jenkins.eztemplates.TemplateProjectListener java.lang.NullPointerException at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:187) at com.google.common.base.Predicates$InPredicate.(Predicates.java:485) at com.google.common.base.Predicates$InPredicate.(Predicates.java:481) at com.google.common.base.Predicates.in(Predicates.java:227) at com.joelj.jenkins.eztemplates.exclusion.Exclusions.configuredExclusions(Exclusions.java:55) at com.joelj.jenkins.eztemplates.utils.TemplateUtils.handleTemplateImplementationSaved(TemplateUtils.java:76) at com.joelj.jenkins.eztemplates.utils.TemplateUtils.handleTemplateSaved(TemplateUtils.java:28) at com.joelj.jenkins.eztemplates.TemplateProjectListener.onUpdated(TemplateProjectListener.java:21) at hudson.model.listeners.ItemListener$3.apply(ItemListener.java:195) at hudson.model.listeners.ItemListener$3.apply(ItemListener.java:193) at hudson.model.listeners.ItemListener.forAll(ItemListener.java:167)
[JIRA] [promoted-builds-plugin] (JENKINS-28533) Promoted build does not respect "Restrict where this promotion process can be run" check with empty label
Title: Message Title juan pablo santos commented on JENKINS-28533 Re: Promoted build does not respect "Restrict where this promotion process can be run" check with empty label Suggested solution still needs some rework on /hudson/plugins/promoted_builds/PromotionProcess/process-config.jelly, as the empty string on the input field is displayed as "". Perhaps would be easier to track the checkbox usage indepently of the input field? Anyway, we managed to bypass our job requirement of executing the promotion on the same node as the job build, so we are moving away from this issue. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [promoted-builds-plugin] (JENKINS-28533) Promoted build does not respect "Restrict where this promotion process can be run" check with empty label
Title: Message Title
juan pablo santos created an issue
Jenkins / JENKINS-28533
Promoted build does not respect "Restrict where this promotion process can be run" check with empty label
Issue Type:
Bug
Assignee:
Unassigned
Components:
promoted-builds-plugin
Created:
21/May/15 4:37 PM
Priority:
Major
Reporter:
juan pablo santos
promoted builds plugin offers a "Restrict where this promotion process can be run" check, which in turn enables an input text label, which is accompanied by a "If not set, the label of the promoted build will be used" text.
So, every time you set the check to restrict where to run the promotion, with an empty label, the promoted job should run in the same node of the label. But if you go to the job's configuration screen, leave it untouched and save it, this parameter is lost and the promotion executes on any given node.
As it turns out, the check to restrict where to run the promotion is enabled or not depending on the value of the label's input text:
/hudson/plugins/promoted_builds/PromotionProcess/process-config.jelly, lines 40-46
"hasAssignedLabel" title="${%Restrict where this promotion process can be run}"
checked="${instance.assignedLabelString!=null}" inline="true">
"${%Label _expression_}"
description="If not set
