With authorization, build job doesn't work using POST request

1.396 does not seem to have this issue; just installing 1.420 to see if this has changed

Hi Tom

I've been unable to reproduce this issue against 1.420 of Jenkins; could you give me a few more details about the environment you are access jenkins from? specifically it would be good to know which operating system and version of python you are using so I can diagnose this issue further.

Also how do you have your instance configured in terms of authentication/authorization?

Thanks

Hi

At the moment I'm just evaluating Jenkins so it's running on a Ubuntu 10.04 32-bit VM, installed from packages using the instructions at https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu. I'm running my Python script on a different machine (actually the VM host, which is running Ubuntu 10.10 32-bit). Python version 2.6.6.

Normally I've been running Jenkins behind an Apache reverse proxy, though to test this bug I disabled that and accessed it directly via Winstone (same issue either way).

Jenkins security is configured as "Jenkins user database", "Matrix-based security".

I'm basically trying to run something like the following script:

j = Jenkins("http://path-to-jenkins/","User","Password")
j.build_job('job', {'PARAMETER': 'blah'})

I added some debug prints into jenkins_open and the other request performed by build_job worked fine (the one triggered by job_exists). It was only the line I quoted in the bug report that failed, and it worked as soon as I removed the empty string parameter.

Here's a wireshark capture of my test script (stuff in square brackets I have removed):
---
GET /jenkins/queue/api/json?depth=0 HTTP/1.1
Accept-Encoding: identity
Host: tom-jdvm:8080
Connection: close
Authorization: Basic [password, encoded]
User-Agent: Python-urllib/2.6

---
HTTP/1.1 200 OK
Server: Winstone Servlet Engine v0.9.10
Content-Type: application/javascript;charset=UTF-8
Content-Length: 12
Connection: Close
Date: Fri, 15 Jul 2011 14:55:05 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)

{"items":[]}
---
GET /jenkins/job/poetry_writer/api/json?depth=0 HTTP/1.1
Accept-Encoding: identity
Host: tom-jdvm:8080
Connection: close
Authorization: Basic [password, encoded]
User-Agent: Python-urllib/2.6

---
HTTP/1.1 200 OK
Server: Winstone Servlet Engine v0.9.10
Content-Type: application/javascript;charset=UTF-8
Content-Length: 3114
Connection: Close
Date: Fri, 15 Jul 2011 14:55:05 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)

[Load of JSON removed]
---
POST /jenkins/job/poetry_writer/buildWithParameters?[URL-encoded parameter string] HTTP/1.1
Accept-Encoding: identity
Content-Length: 0
Host: tom-jdvm:8080
User-Agent: Python-urllib/2.6
Connection: close
Content-Type: application/x-www-form-urlencoded
Authorization: Basic [password, encoded]

---
HTTP/1.1 403 Forbidden
Server: Winstone Servlet Engine v0.9.10
Content-Length: 305
Connection: Close
Content-Type: text/html;charset=UTF-8
Date: Fri, 15 Jul 2011 14:55:05 GMT
X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
Set-Cookie: JSESSIONID=83cc6a68eea0fc3031b92df6dcb9b2eb; Path=/jenkins

With the change I noted in the bug report the last request is a GET and the response is 302 FOUND with a redirect, and most importantly the job gets triggered.

I think this may be a bug in Jenkins not in your Python implementation (or perhaps a feature - I've not yet found any documentation as to whether POST requests are supposed to work?)

If I try submitting a job using wget:

wget --auth-no-challenge --http-user=[user] --http-password=[password] --no-check-certificate https://tom-jdvm.redembedded.com/jenkins/job/poetry_writer/buildWithParameters?[params]

it works, but if I add

--post-data=""

which has the effect of making the request a POST not a GET, I get 403 forbidden.

I'll investigate this further and maybe raise a Jenkins bug.

Sorry for bugging you...

Hi Tom

I still can't reproduce (I've tried running the client from maverick, natty and oneiric) but as switching to GET does not seem to impact on this call I suggest that we go for that; I'll update trunk today - it should get automatically rebuilt into the Daily builds PPA or you can grab the code directly.

I am running the same Jenkins release; however I'm running it on Oneiric/64bit with OpenJDK which may be making a difference.

Cheers

James

I can't actually find any documentation indicating whether the Jenkins design expects POST or GET to be used... so I raised this Jenkins bug: https://issues.jenkins-ci.org/browse/JENKINS-10374

On Tue, 2011-07-19 at 09:02 +0000, Tom Wood wrote:
> I can't actually find any documentation indicating whether the Jenkins
> design expects POST or GET to be used... so I raised this Jenkins bug:
> https://issues.jenkins-ci.org/browse/JENKINS-10374

Nice one - documentation on the remote API is not great; it would be
good to get clarification on what we should be doing.

Thanks for helping out with this bug

Cheers

James

--
James Page
Ubuntu Server Developer

Hi James
I got an email after a post I made on the jenkins mailing list:
"
Do you have CSRF protection enabled? If you do, you need to request a crumb
from the server first, and include that as part of your POST request.

The instructions for how to do this need to be split out into its own page,
but you can find it in the "CSRF Protection" section here:

https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs
"

I did indeed have CSRF protection enabled which might explain why I was seeing the problem and you weren't. (As it happens, this Jenkins instance is only available on an internal company network, so CSRF protection is probably a bit overkill).

I haven't got an explanation as to why things still work if you use a GET request not POST - this would seem to be a hole in the CSRF protection?!

Anyway this sort of explains what was going on.

Tom