Jenkins XSS protection interferes with API access (leads to 403)

Bug #1007261 reported by Paul Sokolovsky
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro Jenkins
Fix Released
Medium
Данило Шеган

Bug Description

Trying to run mangle-jobs script with --really switch (actually write changes back to Jenkins) leads to 403 Forbidden even if user has admin privs. It does authenticate allows to read config though.

Related branches

Revision history for this message
Paul Sokolovsky (pfalcon) wrote :

Latest info from Deepti is that even using account/password backed by Jenkins user database, there's still 403.

summary: - API key auth leads to 403 for write changes
+ API key auth leads to 403 for write access
Revision history for this message
Paul Sokolovsky (pfalcon) wrote : Re: API key auth leads to 403 for write access

Next testcase idea: run it with API keu auth on android-build and see how it goes.

Changed in linaro-jenkins:
status: New → Confirmed
assignee: nobody → Paul Sokolovsky (pfalcon)
importance: Undecided → Medium
Revision history for this message
Paul Sokolovsky (pfalcon) wrote :

Ok,

./mangle-jobs --user=pfalcon build-timeout-set.mangle --really

worked well (changed jobs as expected) on android-build. So, problem is not in Jenkins, but in some peculiarities and/or configuration of ci.linaro.org.

Revision history for this message
Paul Sokolovsky (pfalcon) wrote :

After investigation, I found that 403 Forbidden response is accompanied by:

Jun 4, 2012 10:59:52 AM hudson.security.csrf.CrumbFilter doFilter
WARNING: No valid crumb was included in request for /jenkins/job/precise-armhf-beagleboard/lastBuild/configSubmit. Returning 403.

And traced that to "Prevent Cross Site Request Forgery exploits" being activated on ci.linaro.org (and not on android-build). If it's disabled, mangle-jobs script works as expected. There's also "Enable proxy compatibility" sub-option, but activating it doesn't change the behavior. I.e., to workaround the issue, "Prevent Cross Site Request Forgery exploits" should be turned off while script is being run.

Now, for more sustained solution, further research should be made - for example, it's apparently the case that XSS protection token should not be required for API access, so requiring it is Jenkins bug, but that should be checked yet. Then, we should check if it still would be easy to add token to API calls as a workaround, or if it makes sense to turn off that option permanently.

Revision history for this message
Paul Sokolovsky (pfalcon) wrote :
summary: - API key auth leads to 403 for write access
+ Jenkins XSS protection interferes with API access (leads to 403)
Changed in linaro-jenkins:
milestone: none → 2013.02
assignee: Paul Sokolovsky (pfalcon) → Данило Шеган (danilo)
status: Confirmed → In Progress
Changed in linaro-jenkins:
status: In Progress → Fix Committed
Changed in linaro-jenkins:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.