Closed alefragnani closed 7 years ago
Would really love this
any news on this ?
In fact, it is already supporting authentication. Just provide the username & password/tokenAPI in the URL like this
http://username:token_OR_password@url
and you're all set
@umens I love the idea, and I didn't see your comment until after I submitted a PR.
However, I couldn't get this to work against Jenkins 2.49 using password, in the extension or anywhere else.
@mikepatrick I'm using Jenkins ver. 2.46.1 . my username is actually an email so if you're making a request with an email you have to encode the @ ( replace it with %40 if your are trying manually ) but in my case in the .jenkins file I don't have to do it. It should be took care of in the request function. for the password, I'm using a token which i generated. ( profile page > configure > show API token ) Let me know if it helps :)
@umens Apparently I wasn't reading my own code closely enough.
The changes to the require.get()
call (passing an object containing an auth
object - PR #10 -) were causing my problem. I can authenticate fine using the http://user:pass@url
syntax using mainline.
If username and password are not specified in the .jenkins
file, my code is passing an auth header generated with empty strings. This does seem to take precedence over anything in the url.
It didn't occur to me to try to authenticate this way before I issued the PR.
The implication here is that my changes are breaking changes for anyone who is currently using the http://user:pass@url
syntax to authenticate. I would not have noticed this without your observations.
Possible Directions
.jenkins
file. auth
object to require.get()
if username and password are specified in .jenkins
.user:pass@
syntax is not supported.user:pass@
.I like the second bullet point in my comment above (only pass auth
object if username/password are specified in .jenkins
file).
I really don't like the idea of trying to parse the credentials out of the URL myself (yuck!), and it seems silly to choose one method, rather than just supporting them both.
Going this direction, users would be free to embed their credentials in the URL, or use the newly recognized "username"
and "password"
keys in .jenkins
.
Also, it would keep anything from breaking for users who may already be using the url-embedded approach.
I'll amend the PR to support this.
Hi, just for you to know that I'm looking at this thread 😄
I don't have the need for an authenticated Jenkins config, because the instances that I access are all local. So, I don't know one which would be the better way to support this. For me, having both ways (keep in the URL or add two new keys in .Jenkins
file) it great. As you said, it's not a breaking update 👍
I will look at @mikepatrick PR this weekend and publish the update ASAP.
Thanks for your help 👍
The params (
username
andpassword
) should be added to.jenkins
file