mguymon / lock_jar

LockJar manages Java Jars for Ruby

Home Page:http://mguymon.github.io/lock_jar/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Provide a means for passing user/password credentials for a repository that don't get added to the *.lock files

bigsur0 opened this issue · comments

When doing local development, we have to pass through an authenticated artifactory instance, currently there is no way to make this work unless we do the following in our Buildfile:

repository 'https://user:password@artifactory.foo.com'

Which then includes this full URL in the generated *.lock files that we check into our version control. It would be best if there was a mechanism for authentication that was more robust and didn't end-up with user credentials in a lock file.

Since naether supports passing Auth credentials it should be possible for lock_jar to pass down auth credentials for the user that may be supplied via some type of .lock_jar_auth hidden archive file in the users CWD or similar.

src/main/ruby/naether/runtime.rb
44-    # @param [String] username optional
45:    # @param [String] password optioanl
46:    def add_remote_repository( url, username = nil, password = nil )
47-      if username
48:        @resolver.addRemoteRepositoryByUrl( url, username, password )
49-      else
--
360-    # @option opts [String] :username for optional auth
361:    # @option opts [String] :password for optional auth
362-    # @option opts [String] :pub_key for optional auth
363:    # @option opts [String] :pub_key_passphrase for optional auth
364-    def deploy_artifact( notation, file_path, url, opts = {} )
--
374-      if opts[:username] || opts[:pub_key]
375:        artifact.setAuth(opts[:username], opts[:password], opts[:pub_key], opts[:pub_key_passphrase] )
376-      end

That sounds reasonable. The other option that comes to mind is using ENV. Can support both options, auth by magic file and auth by env.

This in addition to issue 35 is blocking us from doing a much needed upgrade of our app to jruby-9.0.5.0.

Auth by magic file and auth by env sounds good to me. One other consideration that may be worthy to think about now before you start the implementation is, what if I have different credentials per repository url? We don't currently have such a need, but it might be an advanced/edge case and may not be worth solving for in the first pass. Thoughts?

That is a good point. Would be encouraging bad security to force that all repos use the same password by going the ENV route. The magic file can have creds per repo and failback from relative to caller (./.lock_jar_auth) to user's home (~/.lock_jar_auth)

I like your proposal.

Do you need a code review or for us to test this out?

Both would be nice 🔍

Reviewed and it works.

released as lock_jar-0.15.2.gem