Users may now provide a username and password in their .jenkins file, and connect to a secured Jenkins instance.
Acceptance criteria:
Existing users who connect to an unsecured Jenkins instance should be unaffected. They will not have to modify their .jenkins file, and things will continue to work as they have.
Users wishing to connect to a secured Jenkins instance can simply add username and password to their .jenkins file, as outlined in README.
Outline of changes and expected behavior
With these changes, a basic authorization header is always sent to Jenkins.
The credentials will default to empty strings, if not provided in the .jenkins file.
For unsecured Jenkins, the .jenkins file can contain no credentials, empty credentials, or invalid credentials. The connection should succeed in any case.
The AUTHENTICATION NEEDED error will be shown for both missing and incorrect credentials, when connecting to a secured Jenkins instance. This will usually be a 401, rather than 403, since an auth header is always sent.
Testing
I tested this against an unsecured Jenkins instance (v1.647 running on localhost), and a secured Jenkins instance (v2.49 running remotely). VSCode v1.12.2 was used for all testing.
One Final Thought
I considered adding a friendly reminder to the README, warning users not to accidentally check their plain-text passwords (via .jenkins file) into version control.
I went back and forth on this. You'd like to think this is common knowledge, and goes without saying, but perhaps it doesn't hurt to put out some orange safety/education pylons for the beginners in our ranks.
In the end I didn't add any reminder/warning; my reasoning was that I should defer to the maintainer's opinion on the (a) appropriateness/necessity and (b) verbiage of such a message.
First of all, thanks for putting this out here!
New Functionality
Users may now provide a
usernameandpasswordin their.jenkinsfile, and connect to a secured Jenkins instance.Acceptance criteria:
Existing users who connect to an unsecured Jenkins instance should be unaffected. They will not have to modify their
.jenkinsfile, and things will continue to work as they have.Users wishing to connect to a secured Jenkins instance can simply add
usernameandpasswordto their.jenkinsfile, as outlined inREADME.Outline of changes and expected behavior
.jenkinsfile..jenkinsfile can contain no credentials, empty credentials, or invalid credentials. The connection should succeed in any case.AUTHENTICATION NEEDEDerror will be shown for both missing and incorrect credentials, when connecting to a secured Jenkins instance. This will usually be a 401, rather than 403, since an auth header is always sent.Testing
I tested this against an unsecured Jenkins instance (v1.647 running on localhost), and a secured Jenkins instance (v2.49 running remotely). VSCode v1.12.2 was used for all testing.
One Final Thought
I considered adding a friendly reminder to the
README, warning users not to accidentally check their plain-text passwords (via.jenkinsfile) into version control.I went back and forth on this. You'd like to think this is common knowledge, and goes without saying, but perhaps it doesn't hurt to put out some orange safety/education pylons for the beginners in our ranks.
In the end I didn't add any reminder/warning; my reasoning was that I should defer to the maintainer's opinion on the (a) appropriateness/necessity and (b) verbiage of such a message.