alefragnani / vscode-jenkins-status

Jenkins Status Extension for Visual Studio Code
MIT License
27 stars 20 forks source link

Support authentication #2

Closed alefragnani closed 7 years ago

alefragnani commented 8 years ago

The params (username and password) should be added to .jenkins file

vviikk commented 7 years ago

Would really love this

umens commented 7 years ago

any news on this ?

umens commented 7 years ago

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

mikepatrick commented 7 years ago

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

umens commented 7 years ago

@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 :)

mikepatrick commented 7 years ago

@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

mikepatrick commented 7 years ago

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.

alefragnani commented 7 years ago

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 👍