Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-16273

Slaves forbidden to request JNLP anonymously but -jnlpCredentials not offered

      All of my windows salve cannot connect to Jenkins master after upgrading to 1.498. Following messages showed up in slaves' jenkins-slave.err:

      java.io.IOException: Failed to load http://192.168.30.95/jenkins/computer/Fortify%201/slave-agent.jnlp: 403 Forbidden
      at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:238)
      at hudson.remoting.Launcher.run(Launcher.java:200)
      at hudson.remoting.Launcher.main(Launcher.java:173)

          [JENKINS-16273] Slaves forbidden to request JNLP anonymously but -jnlpCredentials not offered

          Stop the Jenkins slave service. Pasting the jnlp url ( http://192.168.30.95/jenkins/login?from=%2Fjenkins%2Fcomputer%2FFortify%25201%2Fslave-agent.jnlp ) in my browser and input my credential, the Jenkins slave agent starts.

          But after I click the File / Install as a service, the attached error message showed up to me.

          Pei-Tang Huang added a comment - Stop the Jenkins slave service. Pasting the jnlp url ( http://192.168.30.95/jenkins/login?from=%2Fjenkins%2Fcomputer%2FFortify%25201%2Fslave-agent.jnlp ) in my browser and input my credential, the Jenkins slave agent starts. But after I click the File / Install as a service, the attached error message showed up to me.

          I confirm this bug for Jenkins 1.498 - it appears although User "anonymous" has Overall-> Read access. Jenkins 1.497 works fine.

          Markus Schulte added a comment - I confirm this bug for Jenkins 1.498 - it appears although User "anonymous" has Overall-> Read access. Jenkins 1.497 works fine.

          Trevor A added a comment -

          We had this issue and were finally able to resolve it by granting the Anonymous user the "Connect" privilege under the "Slave" section. The permissions can be found in the "Authorization" section of the "Configure Global Security" page under "Manage Jenkins."

          Trevor A added a comment - We had this issue and were finally able to resolve it by granting the Anonymous user the "Connect" privilege under the "Slave" section. The permissions can be found in the "Authorization" section of the "Configure Global Security" page under "Manage Jenkins."

          Jesse Glick added a comment -

          This is intentional—part of the security fix. In order to retrieve slave-agent.jnlp now, you need to provide authentication demonstrating that you are permitted to connect to the slave. This is generally done using an API token. Alternately, download the JNLP from your browser (while logged in as an admin) and save that, rather than attempting to connect to slave-agent.jnlp on the fly.

          @trevora: granting the Anonymous user the "Connect" privilege effectively bypasses (part of) the security fix. Do not do this unless you are on a trusted, closed network (in which case why are you running with security at all?).

          Jesse Glick added a comment - This is intentional—part of the security fix. In order to retrieve slave-agent.jnlp now, you need to provide authentication demonstrating that you are permitted to connect to the slave. This is generally done using an API token. Alternately, download the JNLP from your browser (while logged in as an admin) and save that, rather than attempting to connect to slave-agent.jnlp on the fly. @trevora: granting the Anonymous user the "Connect" privilege effectively bypasses (part of) the security fix. Do not do this unless you are on a trusted, closed network (in which case why are you running with security at all?).

          Trevor A added a comment -

          @jglick: Could you please point me to some information on how to properly configure Windows slave agents after the security fix? We are running on a closed network, but I'd prefer to configure it the right way if possible. Any information would be greatly appreciated.

          If I understand correctly, the Windows service downloads and runs the slave-aget.jnlp when it starts using the parameters in the slave-agent.xml file. I'm not sure how to provide it an API key.

          While we are on a closed network, we run security to control who may administer the Jenkins server and who can set up build projects. We thought it best to leave our Anonymous user restricted so non-developers would not have access to the server. We only added the "Connect" privilege to get our system back up and running after the upgrade.

          Trevor A added a comment - @jglick: Could you please point me to some information on how to properly configure Windows slave agents after the security fix? We are running on a closed network, but I'd prefer to configure it the right way if possible. Any information would be greatly appreciated. If I understand correctly, the Windows service downloads and runs the slave-aget.jnlp when it starts using the parameters in the slave-agent.xml file. I'm not sure how to provide it an API key. While we are on a closed network, we run security to control who may administer the Jenkins server and who can set up build projects. We thought it best to leave our Anonymous user restricted so non-developers would not have access to the server. We only added the "Connect" privilege to get our system back up and running after the upgrade.

          Same issue here. Reading through the comments above it made me think: would it be possible to make when jnlp is first started through a web browser to save this jnlp to local Jenkins directory and automatically configure service to use this cached copy instead of requesting it from the server? This would make setting up slaves automatic again without altering security fix.

          Krzysztof Malinowski added a comment - Same issue here. Reading through the comments above it made me think: would it be possible to make when jnlp is first started through a web browser to save this jnlp to local Jenkins directory and automatically configure service to use this cached copy instead of requesting it from the server? This would make setting up slaves automatic again without altering security fix.

          Duane Bronson added a comment -

          @Jesse: This is broken for the "Logged-in users can do anything" authorization policy. The help on that suggest that this is not "security" but instead record keeping, so it really shouldn't be locked down like this. Could we allow slaves access to jnlp in this mode? Or, allow a --auth user:password option to the slave start command which doesn't seem to work right now.

          Context help on "Logged-in users can do anything" from the configureSecurity page:
          "This mode is useful to force users to log in before taking actions, so that you can keep record of who has done what. This setting can be also used in public-facing Jenkins, where you only allow trusted users to have user accounts."

          Duane Bronson added a comment - @Jesse: This is broken for the "Logged-in users can do anything" authorization policy. The help on that suggest that this is not "security" but instead record keeping, so it really shouldn't be locked down like this. Could we allow slaves access to jnlp in this mode? Or, allow a --auth user:password option to the slave start command which doesn't seem to work right now. Context help on "Logged-in users can do anything" from the configureSecurity page: "This mode is useful to force users to log in before taking actions, so that you can keep record of who has done what. This setting can be also used in public-facing Jenkins, where you only allow trusted users to have user accounts."

          Jesper Jensen added a comment -

          The slave agent windows service install is also broken by this change.

          Jesper Jensen added a comment - The slave agent windows service install is also broken by this change.

          Jesse Glick added a comment -

          @nerdmachine: regardless of what the help on “Logged-in users can do anything” may suggest, it is a true security policy and it means that any operation requiring authentication—even GET requests which do produce any “records” to keep—must be accompanied by a valid login token.

          I do not know much about the Windows service; someone who understands this code will need to evaluate how it should be provided with an API token. Without any special (Windows-specific) tool you can always download a *.jnlp file, run it manually, and when prompted ask to save it as a service; this is just a feature of Java WebStart.

          Jesse Glick added a comment - @nerdmachine: regardless of what the help on “Logged-in users can do anything” may suggest, it is a true security policy and it means that any operation requiring authentication—even GET requests which do produce any “records” to keep—must be accompanied by a valid login token. I do not know much about the Windows service; someone who understands this code will need to evaluate how it should be provided with an API token. Without any special (Windows-specific) tool you can always download a *.jnlp file, run it manually, and when prompted ask to save it as a service; this is just a feature of Java WebStart.

          Trevor A added a comment -

          @Pei-Tang, @Jesper: For what it's worth, we found that the Windows service install wasn't broken per se but that it failed if the service already existed. We were able to log onto one of our Windows build servers, manually uninstall the service, rename or delete jenkins-slave.exe and jenkins-slave.xml, reboot the system, and then successfully reinstall the service by logging in as an admin, downloading the .jnlp file, and using the Java WebStart to install it.

          However, even after reinstalling the service the build slave was unable to register with master server because the service was trying to retrieve the the .jnlp from the master each time it started and was being denied.

          I have not tried manually running the .jnlp file outside the browser and installing as suggested above.

          Trevor A added a comment - @Pei-Tang, @Jesper: For what it's worth, we found that the Windows service install wasn't broken per se but that it failed if the service already existed. We were able to log onto one of our Windows build servers, manually uninstall the service, rename or delete jenkins-slave.exe and jenkins-slave.xml , reboot the system, and then successfully reinstall the service by logging in as an admin, downloading the .jnlp file, and using the Java WebStart to install it. However, even after reinstalling the service the build slave was unable to register with master server because the service was trying to retrieve the the .jnlp from the master each time it started and was being denied. I have not tried manually running the .jnlp file outside the browser and installing as suggested above.

          I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue

          The remote management facility of Windows is hard for me to set correctly, I spent more than 6 hours to make all of my 6 Windows slaves run as well as before.

          Pei-Tang Huang added a comment - I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue The remote management facility of Windows is hard for me to set correctly, I spent more than 6 hours to make all of my 6 Windows slaves run as well as before.

          I managed to fix this fairly simply on my windows slaves (tested on XP, Vista & Win 7).

          1 - autheticate as a Jenkins admin in a browser of your choice and download the slave-agent.jnlp file for the slave. The download URL will be something like
          http://<jenkinsurl>/computer/<slavename>/slave-agent.jnlp
          and can be found in the jenkins-slave.xml file on the slave.

          2 - transfer slave-agent.jnlp to the slave and store in the same folder as slave.jar and jenkins-slave.xml files

          3 - edit jenkins-slave.xml and change the URL of slave-agent.jnlp to be
          file:///%BASE%/slave-agent.jnlp
          That means that the arguments line in jenkins-slave.xml will likely read

          <arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpUrl file:///%BASE%/slave-agent.jnlp</arguments>

          Now just start the slave service as normal and all should work.

          Disclaimer: I haven't studied the security implications of storing slave-agent.jnlp at that location in the slave. I suspect it is fine but it would be good if someone could comment on whether there is a better location.

          Richard Mortimer added a comment - I managed to fix this fairly simply on my windows slaves (tested on XP, Vista & Win 7). 1 - autheticate as a Jenkins admin in a browser of your choice and download the slave-agent.jnlp file for the slave. The download URL will be something like http://<jenkinsurl>/computer/<slavename>/slave-agent.jnlp and can be found in the jenkins-slave.xml file on the slave. 2 - transfer slave-agent.jnlp to the slave and store in the same folder as slave.jar and jenkins-slave.xml files 3 - edit jenkins-slave.xml and change the URL of slave-agent.jnlp to be file:///%BASE%/slave-agent.jnlp That means that the arguments line in jenkins-slave.xml will likely read <arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpUrl file:///%BASE%/slave-agent.jnlp </arguments> Now just start the slave service as normal and all should work. Disclaimer: I haven't studied the security implications of storing slave-agent.jnlp at that location in the slave. I suspect it is fine but it would be good if someone could comment on whether there is a better location.

          Jesper Jensen added a comment - - edited

          Based up @Trevor and @Richard instructions here is how I got the windows slaves to run as a service again:
          1 - Stop service
          2 - Uninstall the service if it exists dos (sc delete jenkinsslave-C__Jenkins)
          3 - Delete the old jenkins-slave.exe, slave.jar and jenkins-slave.xml
          4 - Start the web client and let it install the service
          5 - Edit the jenkins-slave.xml so the it looks like this the important part is the jnlpCredentials <arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpCredentials <user>:<password> -jnlpUrl http://<your server>/computer/<slave name>/slave-agent.jnlp</arguments></arguments>
          6 - Stop your web client if it not already and restart your service.

          Mine are now running.

          Note it is very important that you delete your old slave.jar and get the new one via the web install. This works with version 1.499

          To the developer please make a note that slave.jar needs to be updated on the slave when you make a new revision!

          Jesper Jensen added a comment - - edited Based up @Trevor and @Richard instructions here is how I got the windows slaves to run as a service again: 1 - Stop service 2 - Uninstall the service if it exists dos (sc delete jenkinsslave-C__Jenkins) 3 - Delete the old jenkins-slave.exe, slave.jar and jenkins-slave.xml 4 - Start the web client and let it install the service 5 - Edit the jenkins-slave.xml so the it looks like this the important part is the jnlpCredentials <arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpCredentials <user>:<password> -jnlpUrl http://<your server>/computer/<slave name>/slave-agent.jnlp</arguments></arguments> 6 - Stop your web client if it not already and restart your service. Mine are now running. Note it is very important that you delete your old slave.jar and get the new one via the web install. This works with version 1.499 To the developer please make a note that slave.jar needs to be updated on the slave when you make a new revision!

          Rainer Weinhold added a comment - - edited

          You have to pass in an user to authenticate via "-jnlpCredentials jenkinsuser:secret":
          My cmd line:
          java -Xrs -jar "slave.jar" -classpath "patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci/computer/winnt-1/slave-agent.jnlp

          or my jenkins-slve.xml :

          <arguments>-Xrs -jar "%BASE%\slave.jar" -classpath "%BASE%\patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci.../slave-agent.jnlp</arguments>

          The difference to 1.480.1 is that there is now an slave connect/disconnect right which must be given to the "jenkinsuser" (Beside overall read)

          The slave installer has the bug that it does not write a correct .xml file with credentials, you have to add this manually. (For LTS the common-codec-1.5.jar had to be added to the classpath, because otherwiese the authentication is missing a base64 codec : JENKINS-9679)

          -> this works on 1.480.2

          Rainer Weinhold added a comment - - edited You have to pass in an user to authenticate via "-jnlpCredentials jenkinsuser:secret": My cmd line: java -Xrs -jar "slave.jar" -classpath "patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci/computer/winnt-1/slave-agent.jnlp or my jenkins-slve.xml : <arguments>-Xrs -jar "%BASE%\slave.jar" -classpath "%BASE%\patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci.../slave-agent.jnlp </arguments> The difference to 1.480.1 is that there is now an slave connect/disconnect right which must be given to the "jenkinsuser" (Beside overall read) The slave installer has the bug that it does not write a correct .xml file with credentials, you have to add this manually. (For LTS the common-codec-1.5.jar had to be added to the classpath, because otherwiese the authentication is missing a base64 codec : JENKINS-9679 ) -> this works on 1.480.2

          alexlombardi added a comment -

          @Pei-Tang Huang: "I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue"

          I tried this but kept getting error:

          Connecting to JenkinsSlave1
          ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins
          java.net.UnknownHostException: JenkinsSlave1
          at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
          at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source)
          at java.net.InetAddress.getAddressFromNameService(Unknown Source)
          at java.net.InetAddress.getAllByName0(Unknown Source)
          at java.net.InetAddress.getAllByName(Unknown Source)
          at java.net.InetAddress.getAllByName(Unknown Source)
          at java.net.InetAddress.getByName(Unknown Source)
          at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:202)
          at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204)
          at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)

          Even though I have verified that's the correct slave/service name.

          alexlombardi added a comment - @Pei-Tang Huang: "I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue" I tried this but kept getting error: Connecting to JenkinsSlave1 ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins java.net.UnknownHostException: JenkinsSlave1 at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source) at java.net.InetAddress.getAddressFromNameService(Unknown Source) at java.net.InetAddress.getAllByName0(Unknown Source) at java.net.InetAddress.getAllByName(Unknown Source) at java.net.InetAddress.getAllByName(Unknown Source) at java.net.InetAddress.getByName(Unknown Source) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:202) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Even though I have verified that's the correct slave/service name.

          alexlombardi added a comment - - edited

          Download the slave-agent.jnlp to the directory where the jenkins-slave.exe is

          How are you accomplishing this? When I trigger the URL I do not get any option to do a download and the agent immediately launches.

          alexlombardi added a comment - - edited Download the slave-agent.jnlp to the directory where the jenkins-slave.exe is How are you accomplishing this? When I trigger the URL I do not get any option to do a download and the agent immediately launches.

          @alexlombardi: java.net.UnknownHostException: JenkinsSlave1

          Verify that the hostname of your slave is "JenkinsSlave1", or you can specify IP address of your slave in the "Host" field.

          Pei-Tang Huang added a comment - @alexlombardi: java.net.UnknownHostException: JenkinsSlave1 Verify that the hostname of your slave is "JenkinsSlave1", or you can specify IP address of your slave in the "Host" field.

          alexlombardi added a comment -

          @Pei-Tang Huang

          My serice name is JenkinsSlave1. I have used the IP address of the server it is running on as you suggest but that fails with this message:

          ERROR: Message not found for errorCode: 0x00001031
          org.jinterop.dcom.common.JIException: Message not found for errorCode: 0x00001031
          at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKCR(JIWinRegStub.java:123)
          at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:479)
          at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427)
          at org.jvnet.hudson.wmi.WMI.connect(WMI.java:59)
          at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:218)
          at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204)
          at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)
          Caused by: java.net.MalformedURLException: For input string: "xuy56qrH@10.41.98.169"
          at java.net.URL.<init>(Unknown Source)
          at jcifs.smb.SmbFile.<init>(SmbFile.java:444)
          at jcifs.smb.SmbNamedPipe.<init>(SmbNamedPipe.java:134)
          at rpc.ncacn_np.RpcTransport.attach(RpcTransport.java:89)
          at rpc.Stub.attach(Stub.java:104)
          at rpc.Stub.call(Stub.java:109)
          at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKCR(JIWinRegStub.java:119)
          ... 10 more

          alexlombardi added a comment - @Pei-Tang Huang My serice name is JenkinsSlave1. I have used the IP address of the server it is running on as you suggest but that fails with this message: ERROR: Message not found for errorCode: 0x00001031 org.jinterop.dcom.common.JIException: Message not found for errorCode: 0x00001031 at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKCR(JIWinRegStub.java:123) at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:479) at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427) at org.jvnet.hudson.wmi.WMI.connect(WMI.java:59) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:218) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: For input string: "xuy56qrH@10.41.98.169" at java.net.URL.<init>(Unknown Source) at jcifs.smb.SmbFile.<init>(SmbFile.java:444) at jcifs.smb.SmbNamedPipe.<init>(SmbNamedPipe.java:134) at rpc.ncacn_np.RpcTransport.attach(RpcTransport.java:89) at rpc.Stub.attach(Stub.java:104) at rpc.Stub.call(Stub.java:109) at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKCR(JIWinRegStub.java:119) ... 10 more

          Jesse Glick added a comment -

          The javaws command unfortunately does not seem to handle passwords or API tokens; so while curl is fine with http://user:pass@host:8080/computer/stuff/slave-agent.jnlp the same passed to javaws just gives a 403. Same for java -jar slave.jar -jnlpUrl … it seems; need to pass -jnlpCredentials to set up a headless slave, which the slave page under Connect slave to Jenkins one of these ways fails to mention.

          Then there is the problem that the installer fails to define -jnlpCredentials in your new jenkins-slave.xml; and JENKINS-9679 can make this not work unless you clear some obscure caches first.

          Seems URL.openConnection fails to parse out the username and password, or is just waiting for a BASIC auth challenge which never comes, due to Jenkins security policy?

          Jesse Glick added a comment - The javaws command unfortunately does not seem to handle passwords or API tokens; so while curl is fine with http://user:pass@host:8080/computer/stuff/slave-agent.jnlp the same passed to javaws just gives a 403. Same for java -jar slave.jar -jnlpUrl … it seems; need to pass -jnlpCredentials to set up a headless slave, which the slave page under Connect slave to Jenkins one of these ways fails to mention. Then there is the problem that the installer fails to define -jnlpCredentials in your new jenkins-slave.xml ; and JENKINS-9679 can make this not work unless you clear some obscure caches first. Seems URL.openConnection fails to parse out the username and password, or is just waiting for a BASIC auth challenge which never comes, due to Jenkins security policy?

          Jesse Glick added a comment -

          Another annoyance: JNLPLauncher/main.jelly only displays these things when <l:isAdmin>, i.e. you have ADMINISTER, when only CONNECT (on that Computer) should be needed.

          Jesse Glick added a comment - Another annoyance: JNLPLauncher/main.jelly only displays these things when <l:isAdmin> , i.e. you have ADMINISTER , when only CONNECT (on that Computer ) should be needed.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly
          http://jenkins-ci.org/commit/jenkins/a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e
          Log:
          JENKINS-16273 Improved instructions for passing -jnlpCredentials.
          First, display instructions when the user has CONNECT, not necessarily ADMINISTER.
          Second, when anonymous users cannot CONNECT, show how to use -jnlpCredentials
          (and do not bother showing javaws, since it does not work in this case).

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly http://jenkins-ci.org/commit/jenkins/a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e Log: JENKINS-16273 Improved instructions for passing -jnlpCredentials. First, display instructions when the user has CONNECT, not necessarily ADMINISTER. Second, when anonymous users cannot CONNECT, show how to use -jnlpCredentials (and do not bother showing javaws, since it does not work in this case).

          Jesse Glick added a comment -

          Fixed the display of the slave overview page. Leaving open since the slave installers do not write out -jnlpCredentials yet.

          Jesse Glick added a comment - Fixed the display of the slave overview page. Leaving open since the slave installers do not write out -jnlpCredentials yet.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2206
          JENKINS-16273 Improved instructions for passing -jnlpCredentials. (Revision a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e)

          Result = SUCCESS
          Jesse Glick : a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e
          Files :

          • core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #2206 JENKINS-16273 Improved instructions for passing -jnlpCredentials. (Revision a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e) Result = SUCCESS Jesse Glick : a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e Files : core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly changelog.html

          Jesse Glick added a comment -

          Considering fixed. The outstanding issue of slave installers is trickier and has broader implications, filed separately as SECURITY-54.

          Jesse Glick added a comment - Considering fixed. The outstanding issue of slave installers is trickier and has broader implications, filed separately as SECURITY-54.

          Duane Bronson added a comment -

          @Jesse - thank you for taking a closer look at this. I have resorted to running without security in hopes that a better solution will be found for the "Logged-in users can do anything" authorization policy.

          How can I track SECURITY-54? Is the SECURITY project restricted from the general public? https://issues.jenkins-ci.org/secure/BrowseProjects.jspa shows the project, but it looks like it contains no issues.

          Duane Bronson added a comment - @Jesse - thank you for taking a closer look at this. I have resorted to running without security in hopes that a better solution will be found for the "Logged-in users can do anything" authorization policy. How can I track SECURITY-54? Is the SECURITY project restricted from the general public? https://issues.jenkins-ci.org/secure/BrowseProjects.jspa shows the project, but it looks like it contains no issues.

          Jesse Glick added a comment -

          @nerdmachine there is no need to run without security; you just need to manually specify -jnlpCredentials user:apitoken in jenkins-slave.xml.

          The SECURITY project is indeed restricted. See https://wiki.jenkins-ci.org/display/JENKINS/Security+Advisories for information.

          Jesse Glick added a comment - @nerdmachine there is no need to run without security; you just need to manually specify -jnlpCredentials user:apitoken in jenkins-slave.xml . The SECURITY project is indeed restricted. See https://wiki.jenkins-ci.org/display/JENKINS/Security+Advisories for information.

          Jesse Glick added a comment -

          Tested workaround for the combination of this and JENKINS-9679 in 1.480.2 for Windows service users on XP:

          1. Remove any existing service. (jenkins-slave.exe uninstall or see http://stackoverflow.com/a/197941/12916 for removing the service entry; and delete the slave directory.)
          2. From Windows slave machine, log in, browse to slave page, and click on the JNLP launch button; slave should start.
          3. Request Windows service installation.
          4. Stop service if you started it. (Control Panel » Admin Tools » Services)
          5. Copy your downloaded jenkins-slave.jnlp somewhere permanent, such as the slave FS root.
          6. Open jenkins-slave.xml in Notepad, find the -jnlpUrl, and change it to point to the downloaded JNLP. This will be a file-protocol URL and must use forward slashes like any URL, e.g.:
            -jnlpUrl file:/C:/jenkins/slave-agent.jnlp
          7. Start service. The slave should now be connected, and should reconnect properly after a reboot.

          Jesse Glick added a comment - Tested workaround for the combination of this and JENKINS-9679 in 1.480.2 for Windows service users on XP: Remove any existing service. ( jenkins-slave.exe uninstall or see http://stackoverflow.com/a/197941/12916 for removing the service entry; and delete the slave directory.) From Windows slave machine, log in, browse to slave page, and click on the JNLP launch button; slave should start. Request Windows service installation. Stop service if you started it. (Control Panel » Admin Tools » Services) Copy your downloaded jenkins-slave.jnlp somewhere permanent, such as the slave FS root. Open jenkins-slave.xml in Notepad, find the -jnlpUrl , and change it to point to the downloaded JNLP. This will be a file -protocol URL and must use forward slashes like any URL, e.g.: -jnlpUrl file:/C:/jenkins/slave-agent.jnlp Start service. The slave should now be connected, and should reconnect properly after a reboot.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly
          http://jenkins-ci.org/commit/jenkins/17f0161e56dc2eb213415528061d8c8792694960
          Log:
          JENKINS-16273 Improved instructions for passing -jnlpCredentials.
          First, display instructions when the user has CONNECT, not necessarily ADMINISTER.
          Second, when anonymous users cannot CONNECT, show how to use -jnlpCredentials
          (and do not bother showing javaws, since it does not work in this case).(cherry picked from commit a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e)

          Conflicts:
          changelog.html

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly http://jenkins-ci.org/commit/jenkins/17f0161e56dc2eb213415528061d8c8792694960 Log: JENKINS-16273 Improved instructions for passing -jnlpCredentials. First, display instructions when the user has CONNECT, not necessarily ADMINISTER. Second, when anonymous users cannot CONNECT, show how to use -jnlpCredentials (and do not bother showing javaws, since it does not work in this case).(cherry picked from commit a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e) Conflicts: changelog.html

          The new documentation is very helpful thank-you. I had no idea that you could use the user API key.

          Walter Kacynski added a comment - The new documentation is very helpful thank-you. I had no idea that you could use the user API key.

          Jesse Glick added a comment -

          @walterk82—yes this was always a possibility. There is a further change (SECURITY-54) which would supersede this technique, and may make it into 1.480.3, but it is still pending review.

          Jesse Glick added a comment - @walterk82—yes this was always a possibility. There is a further change (SECURITY-54) which would supersede this technique, and may make it into 1.480.3, but it is still pending review.

            Unassigned Unassigned
            beta Pei-Tang Huang
            Votes:
            14 Vote for this issue
            Watchers:
            26 Start watching this issue

              Created:
              Updated:
              Resolved: