• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    •  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

      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

          Bruce Coveny created issue -

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          Bruce Coveny added a comment -

          /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)

          Bruce Coveny added a comment - /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)

          Daniel Beck added a comment -

          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).

          Daniel Beck added a comment - 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).

          Bruce Coveny added a comment -

          The who-am-i has no bearing on this as I pass in --username %username and --password $password.

          Bruce Coveny added a comment - The who-am-i has no bearing on this as I pass in --username %username and --password $password.

          Daniel Beck added a comment -

          Based on the stack trace, Jenkins thinks you're unauthenticated.

          Daniel Beck added a comment - Based on the stack trace, Jenkins thinks you're unauthenticated.

          Bruce Coveny added a comment -

          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?

          Bruce Coveny added a comment - 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?

          Daniel Beck added a comment -

          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).

          Daniel Beck added a comment - 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).

          Bruce Coveny added a comment -

          cli cancel-quiet-down security

          Bruce Coveny added a comment - cli cancel-quiet-down security
          Bruce Coveny made changes -
          Attachment New: jenkins_cancel_quiet_down_cli_error.png [ 26435 ]

            Unassigned Unassigned
            bcoveny Bruce Coveny
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: