-
Bug
-
Resolution: Fixed
-
Critical
-
JENKINS WAR VERSION 1.573
WINDOWS SERVER 2008 R2 ENTERPRISE
AMD OPTERON(TM) PROCESSOR 6136 2.4 GHZ (2 PROCESSORS)
4.0 GB RAM
64-BIT OPERATION SYSTEM
WEBSPHERE APPLICATION SERVER 8.5.5
-
Powered by SuggestiMate
When going to Manage Jenkins and clicking Prepare for Shutdown the /quietDown throws a HTTP 405 Method Not Allowed. I cannot find anything in any logs as to why.
[JENKINS-23942] quietDown reports HTTP 405 Method Not Allowed
/quietDown did not work on 1.572 or 1.573 for me. I cannot use a "pristine" version of Jenkins as I can only use the instances of Jenkins we have. I think the @RequirePOST is potentially the issue here. The other thing I am seeing (which could be related) is using the CLI jar and attempting to do quiet-down doesn't work either. I get the exception noted below even though the username I am using has the Overall/Administer permission.
hudson.security.AccessDeniedException2: anonymous is missing the Overall/Administer permission
at hudson.security.ACL.checkPermission(ACL.java:55)
at hudson.model.Node.checkPermission(Node.java:417)
at jenkins.model.Jenkins.doQuietDown(Jenkins.java:2892)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at hudson.cli.declarative.MethodBinder.call(MethodBinder.java:102)
at hudson.cli.declarative.CLIRegisterer$1.main(CLIRegisterer.java:185)
at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:309)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:290)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:249)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63)
at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:149)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:773)
Re CLI: Then your authentication doesn't work. Try jenkins -jar jenkins-cli.jar ... who-am-i. But that's an entirely different issue.
As mentioned in a comment on the PR, the @RequirePOST doesn't seem to have an effect for some reason on the overloads, at least on a default install. Otherwise, more users would complain about this then rather than JENKINS-23020 (as the only way there is to not have this issue).
The who-am-i has no bearing on this as I pass in --username %username and --password $password.
I understand that but I am obviously passing in the credentials much like that should be passed to the /quietDown URL when logged in from the screens. I feel this is the issue that the credentials are not properly supplied and generating the error HTTP 405 as well as the cli throwing the error thinking that I am anonymous which doesn't have the proper permissions where my username does have the proper permissions. With you saying this is working in 1.572 and 1.573 is your instance configured with security and the anonymous account not having the overall/administer permission? Can you try to change that and see if your errors like this?
CLI is a bit weird about argument order, so that could be the cause.
Re the basic issue, I tried on both Jenkins 1.572 and 1.573 running on bundled Jetty and neither prevented /quietDown from working (even if accessing the URL directly). OTOH canceling it again does not work. 'Try POSTing instead' on the UI (and even that fails when CSRF crumbs are configured).
So your testing on 1.572 and 1.573 was without security enabled?
I gave anonymous Overall/Administer permission and the /quietDown still gives me HTTP 405 error. I then tried the cli again and the cli now works with quiet-down. The /cancelQuietDown gives me the HTTP 405 error as well. The cli for cancel-quiet-down works. I then took the security option for Overall/Adminsiter back away and the cancel-quiet-down fails. (Added image of this situation to request)
Let's table the CLI issue for now. I can reproduce the issue and have a working hypothesis about the reason, will file this separately if I can get confirmation later today. Workaround: Use an SSH key for authentication.
Re my testing: That was
- via the GUI (both clicking the management link and navigating to /quietDown manually),
- with security enabled,
- CSRF crumb enabled/disabled did not make any difference,
- anonymous having NO permissions,
- on 1.572 and 1.573.
- Jenkins running on CentOS, OpenJDK 7, embedded Jetty
Should be easy enough to set up an ad-hoc Jenkins instance on a local desktop or so and use Jenkins internal user DB to test whether the issue occurs there as well. Don't have a Windows box right now to reproduce your setup (and no Websphere for that matter!)
Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/model/ManagementLink.java
core/src/main/java/jenkins/management/ShutdownLink.java
core/src/main/resources/jenkins/model/Jenkins/manage.jelly
core/src/main/resources/lib/form/link.jelly
core/src/main/resources/lib/form/link/link.js
core/src/main/resources/lib/hudson/queue.jelly
http://jenkins-ci.org/commit/jenkins/fda84f456f4be4f48048970a6055399f17761ab0
Log:
Merge pull request #1306 from bkmeneguello/post-cancel-shutdown
[FIXED JENKINS-23020 JENKINS-23942] Convert the queue's cancel shutdown to POST
Compare: https://github.com/jenkinsci/jenkins/compare/2b6c00db3406...fda84f456f4b
Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/model/ManagementLink.java
core/src/main/java/jenkins/management/ShutdownLink.java
core/src/main/resources/jenkins/model/Jenkins/manage.jelly
core/src/main/resources/lib/form/link.jelly
core/src/main/resources/lib/form/link/link.js
core/src/main/resources/lib/hudson/queue.jelly
http://jenkins-ci.org/commit/jenkins/b73bb3d0af419dd653b743b4c0b8458c965396e1
Log:
Merge pull request #1306 from bkmeneguello/post-cancel-shutdown
[FIXED JENKINS-23020 JENKINS-23942] Convert the queue's cancel shutdown to POST
(cherry picked from commit fda84f456f4be4f48048970a6055399f17761ab0)
Since 1.561 some actions require POST requests. Unfortunately, the UI hasn't been adjusted accordingly for some, see comments to https://github.com/jenkinsci/jenkins/pull/877
That said, /quietDown works on 1.572 and 1.573 for me. It's cancelling that's a problem, see
JENKINS-23020. Are you able to reproduce the problem on a pristine Jenkins instance, using the embedded Jetty?https://github.com/jenkinsci/jenkins/pull/1306 may fix this as well anyway.