Minor I stepwise tried to harden my local hudson installation.
Security realm is set to "Active Directory".
From the Anonymous user I removed all Authorization rights. This broke
triggering hudson builds using URL with token.
To make it work again I had to assign the "Overall -> read" right to the
Anonymous user.
Actually, I didn't wanted to have Anonymous users see project details. Could the
current behavior be changed by checking the "Job -> Build" right prior to
triggered builds?
- is blocking
-
JENKINS-1678 Securing Remote Triggers with tokens not working
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
[JENKINS-1555] Remote triggering of builds requires anonymous user Read permission
I think more general approach to the delegation of authority is necessary (and this is the line of reasoning that deprecated the build token support.)
For example, Hudson can generate a digital signature from the path, the user, and the expiration date, and if this digital signature is present in the request and the path is the same, we could allow the request to be handled under the credential of the user.
Walter Kacynski
added a comment - This is a fairly old issue and judging from all of the linked issues, it doesn't seem to be address. Are there any know workarounds for the time being? Is allowing anonymous "Read" to all Jobs required for CLI or SSH access?
Walter Kacynski
added a comment - This is a fairly old issue and judging from all of the linked issues, it doesn't seem to be address. Are there any know workarounds for the time being? Is allowing anonymous "Read" to all Jobs required for CLI or SSH access? 
Herbert Vojčík
added a comment - Hi, it does not work for me, too (1.458, freebsd). Strange is, IIRC it worked on 1.454 or so, I did not give anonymous any access and it worked. Now, it is problem unless I goive anonymous overall read as well as job read.
Herbert Vojčík
added a comment - Hi, it does not work for me, too (1.458, freebsd). Strange is, IIRC it worked on 1.454 or so, I did not give anonymous any access and it worked. Now, it is problem unless I goive anonymous overall read as well as job read. 
cosmo king
added a comment - If build token trigger support is deprecated, why is it still the preferred job trigger mechanism for a continuous integration environment?
Isn't this kind of an essential feature in CI workflows? Also, securing Jenkins in this manner to disallow anonymous access also seems essential in many environments.
I installed the Build Token Root Plugin, but it didn't seem to work. I guess we will go back to polling the SCM.
Seems like regardless, there should be a conclusion to this bug on the Jenkins base distribution.
cosmo king
added a comment - If build token trigger support is deprecated, why is it still the preferred job trigger mechanism for a continuous integration environment?
Isn't this kind of an essential feature in CI workflows? Also, securing Jenkins in this manner to disallow anonymous access also seems essential in many environments.
I installed the Build Token Root Plugin, but it didn't seem to work. I guess we will go back to polling the SCM.
Seems like regardless, there should be a conclusion to this bug on the Jenkins base distribution. I installed the Build Token Root Plugin, but it didn't seem to work.
Read its documentation.
ken liao
added a comment - I got this issue too, after upgraded to Jenkins 2.222.3, "build token trigger" doesn't work anymore, it needs to assign "read" permission to "anonymous". I also installed "Build Token Root Plugin" but it didn't work
ken liao
added a comment - I got this issue too, after upgraded to Jenkins 2.222.3, "build token trigger" doesn't work anymore, it needs to assign "read" permission to "anonymous". I also installed "Build Token Root Plugin" but it didn't work 
improving defect summary