can't trigger remote buildWithParameters to save my life

[Sorin]

Hi all,

I'm using a password-secured Jenkins 2.1 on Windows for a parameterized build project with a remote build trigger (and its auth token). I am trying to craft a HTTP request for a REST client so I need to know how the request must actually be - without curl command-line parameters. If there is a RTFM for this matter I constantly failed to find it, please help.

Here's what I tried so far:
- sending a GET or PUT request with URL encoded parameters, failed miserably .../buildWithParameters?token=MY_TOKEN&myparam=VALUE answers dryly 403 forbidden (why forbidden?)
- sending a POST request with payload like json='{"parameter":[{"myparam":"VALUE"}]}' (or any other payload for that matter, stackoverflow has conflicting answers) gives me a 403 "no valid crumb...". There seem to be people on the internet which know that some ".crumb" must be changed but nothing says WHAT that dot-crumb is, who generates it, or how should it look like.

I googled in the Wiki a page about a "parameterized remote trigger" which may or may not be the one I use above (I know now way to tell for sure, update center names are different from Wiki plugin names) but there's no plugin with a similar-sounding name available in the update center. I'm so very stuck... halp!!!

Many thanks,
Sorin

[Daniel Beck]

> On 10.05.2016, at 10:13, Sorin <sot...@gmail.com> wrote:
>
> - sending a GET or PUT request with URL encoded parameters, failed miserably .../buildWithParameters?token=MY_TOKEN&myparam=VALUE answers dryly 403 forbidden (why forbidden?)

The token only allows building if the authentication otherwise allows read access to the job.

> - sending a POST request with payload like json='{"parameter":[{"myparam":"VALUE"}]}' (or any other payload for that matter, stackoverflow has conflicting answers) gives me a 403 "no valid crumb...". There seem to be people on the internet which know that some ".crumb" must be changed but nothing says WHAT that dot-crumb is, who generates it, or how should it look like.

https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API#RemoteaccessAPI-CSRFProtection

Note that passing the JSON string is a hackish unsupported solution -- this approach emulates what a web browser does, and the browser submits whatever the "Build with Parameters" form tells him to, i.e. there's no reasonable expectation of backwards compatibility if we ever change the form.

[S C]

On Tue, May 10, 2016 at 10:53 AM, Daniel Beck <m...@beckweb.net> wrote:

> On 10.05.2016, at 10:13, Sorin <sot...@gmail.com> wrote:
>
> - sending a GET or PUT request with URL encoded parameters, failed miserably .../buildWithParameters?token=MY_TOKEN&myparam=VALUE answers dryly 403 forbidden (why forbidden?)

The token only allows building if the authentication otherwise allows read access to the job.

Thank you - I went to Jenkins general security settings, enabled anon users readonly access and lo, triggering builds with the GET URL works!

 

> - sending a POST request with payload like json='{"parameter":[{"myparam":"VALUE"}]}' (or

 

Note that passing the JSON string is a hackish unsupported solution -- this approach emulates what a web browser does, and the browser submits whatever the "Build with Parameters" form tells him to, i.e. there's no reasonable expectation of backwards compatibility if we ever change the form.

I think people try these hackish solutions when they aren't shown any recommended solution. Could we (I'd gladly do it) add the above answer to the relevant Jenkins page, so nobody has to lose hours like I did?

Many thanks

Sorin

[S C]

Oh and a PUT can trigger as well - I'll rather take PUT.

Many thanks again,

Sorin

[Björn Pedersen]

Hi,

And take a look at https://wiki.jenkins-ci.org/display/JENKINS/Build+Token+Root+Plugin as well. This should help you to not require overall read permissions.

Björn

[S C]

Oh this is really useful indeed - and it doesn't require those senseless (nb: senseless in a build trigger case) crumbs either. Thanks a lot!

Sorin

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/DXhHQbp6zUw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e78fba1a-eef9-4142-8c7b-49d6052df692%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Daniel Beck]

> On 11.05.2016, at 09:46, S C <sot...@gmail.com> wrote:
>
> I think people try these hackish solutions when they aren't shown any recommended solution. Could we (I'd gladly do it) add the above answer to the relevant Jenkins page, so nobody has to lose hours like I did?

https://yourjenkins/job/whatever/api documents the job-related API. The section "Perform a build" will explain how to do this. It's linked from the job page's footer.

[S C]

Thanks a lot, really comprehensive info on that page. It's just too bad a Google search won't show the same, because I had no idea there'd be anything interesting in the footer (I never scroll until there).

However: the page only talks about POSTing to URL, says nothing about sending URL parameters with PUT (or GET), and also recommends - guess what - the "hackish" way of sending the params as form data! It even says that using the remote trigger plugin is "deprecated" so... if I'm not mistaking it goes exactly against all the recommendations above.

As for myself I'm very happy with your recommendation so I'll ignore the Jenkins info page. Triggering a state change with PUT seems to me anyway the RESTful way, not POSTing some transient data :) Now if only GETting from that trigger address would return me "building job xyz..." if still building and the (latest if done) build location - instead of triggering a new build... Now that GET will change state and in the event of a automatic retry - not so unheard-of - would try to change state many times, then it would be a perfect world! But that's first world problems indeed ;)

It's also worth noticing that I cannot cancel in GUI a build job queued via remote trigger. I guess because it was not queued by my GUI user - it makes sense but still not very convenient (I'm in GUI an admin user so I had expectations...).

Thank you for taking your time to answer!

Sorin

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/DXhHQbp6zUw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/947CBB5F-256D-4E6B-987A-7845C3AB5858%40beckweb.net.

[Daniel Beck]

> On 11.05.2016, at 14:41, S C <sot...@gmail.com> wrote:
>
> However: the page only talks about POSTing to URL, says nothing about sending URL parameters with PUT (or GET), and also recommends - guess what - the "hackish" way of sending the params as form data! It even says that using the remote trigger plugin is "deprecated" so... if I'm not mistaking it goes exactly against all the recommendations above.

Yes, the parameters. Not the JSON object.

Due to the problems with requiring read access to use the token you experienced, I generally recommend against using the trigger token. We really should move this into a plugin and let it fade away…

> Now if only GETting from that trigger address would return me "building job xyz..." if still building and the (latest if done) build location - instead of triggering a new build... Now that GET will change state and in the event of a automatic retry - not so unheard-of - would try to change state many times, then it would be a perfect world!

How would that work with parallel builds, etc.? Admittedly, not the cleanest of APIs, but you should be able to achieve your goals anyway. The API, if used correctly, will return the queue item URL whose API you can query for status.

> It's also worth noticing that I cannot cancel in GUI a build job queued via remote trigger. I guess because it was not queued by my GUI user - it makes sense but still not very convenient (I'm in GUI an admin user so I had expectations...).

Very unusual. This is not the case with Jenkins out of the box, so it's possible a plugin interferes.