feat: support basic-auth for loading scripts

[micmeyer]

Adds support for basic-auth when loading a script.

Usage:
export JBANG_BASIC_AUTH_USERNAME=
export JBANG_BASIC_AUTH_PASSWORD=
jbang https:///.....

[maxandersen]

hmm - I understand the need but would it make more sense we used maven style config for this ? basically use auth settings in /.m2/pom.xml ?

[micmeyer]

Being able to store credentials in a file would definitely be nice. From a security point of view the credentials would have to be encrypted tough.

Maven and Ansible use a "master password" for this:

• Maven: https://blog.sonatype.com/2009/10/maven-tips-and-tricks-encrypting-passwords/
• Ansible: https://docs.ansible.com/ansible/latest/user_guide/vault.html

With the "tooling" that is needed for users to encrypt individual passworts (Maven) or a whole file (Ansible) this would become quite a big feature.

I liked the solution that was chosen for the GITHUB_TOKEN (#590) since one doesn't have to store unencrypted passwords in a file.

[micmeyer]

@maxandersen I would really like to see support for Basic-Auth in JBang. This would allow us to have branch-specific scrips for setting up a workspace.
Any chance that this pull request will be merged? Or are you planning to add this functionality in combination with a bigger refactoring that supports encrypted configuration properties/files?

[maxandersen]

I want something like this in too but just considering how. I know that the single global env variable won't work in the long run though. Thus im being hesitant to just add it straight up.

[quintesse]

@maxandersen I do feel the same way as you , but after having thought about it I'm not coming up with alternatives that are much better, I also imagine that we won't support many more different authentication schemes so we'd probably have something like BEARER and TOKEN and that's it, right? It also seems that most services like GitHub or anything container based tend to depend on passing secrets using environment variables. Given all that I'm leaning towards applying this.

NB: The only thing I would like to see changed is the naming of the variables: JBANG_AUTH_BASIC_USERNAME and JBANG_AUTH_BASIC_PASSWORD, so future extensions would be likewise named, eg: JBANG_AUTH_BEARER, JBANG_AUTH_TOKEN, etc.

[codecov]

Codecov Report

Base: 0.00% // Head: 0.00% // No change to project coverage 👍

Coverage data is based on head (b739775) compared to base (35d2038).
Patch coverage: 0.00% of modified lines in pull request are covered.

❗ Current head b739775 differs from pull request most recent head 7a82b94. Consider uploading reports for the commit 7a82b94 to get more accurate results

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #1516   +/-   ##
=====================================
  Coverage   0.00%   0.00%           
=====================================
  Files        110     110           
  Lines       6977    6985    +8     
  Branches    1141    1142    +1     
=====================================
- Misses      6977    6985    +8     

Flag	Coverage Δ
Linux	0.00% <0.00%> (ø)
Windows	0.00% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/main/java/dev/jbang/util/Util.java	0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[micmeyer]

Naming updated according to the feedback of @quintesse .

[quintesse]

LGTM

[maxandersen]

merging with the understanding we'll want to broaden this in future. we'll treat the JBANG_AUTH as fallback values on hosts without specific setting in future.