SBT is unable to find credentials when attempting to download from an Artifactory virtual repo

Question

I'm trying to run SBT behind a corporate firewall. Another team has configured an Artifactory proxy. This proxy works fine with anonymous access switched on, but when we make it require a password thinks start to go wrong.

When I run SBT on my workstation I get the following error:

[error] Unable to find credentials for [Artifactory Realm @ coderepo.xxx.amrs.bigco.com]

The result of this is that I cannot bootstrap sbt:

[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  ::          UNRESOLVED DEPENDENCIES         ::
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::
[warn]  :: org.scala-lang#scala-library;2.10.6: not found
[warn]  :: org.scala-sbt#sbt;0.13.12: not found
[warn]  :: org.scala-lang#scala-compiler;2.10.6: not found
[warn]  ::::::::::::::::::::::::::::::::::::::::::::::

I've tried putting a .credentials file in ~/.sbt and also ~/.ivy2: I have been testing variations on the following, all of which do not work:

realm=Artifactory Realm @ coderepo.xxx.amrs.bigco.com
host=coderepo.xxx.amrs.bigco.com
user=<username>
password=<pwd>

I'm guessing that this error means that it was unable to locate a credentials definition that matched the realm, so I tried a number of versions of the first line in both locations:

realm=Artifactory Realm
realm=[Artifactory Realm @ coderepo.xxx.amrs.bigco.com]
realm=coderepo.xxx.amrs.bigco.com

None of which seem to have any impact at all.

So what is the correct way to allow SBT to authenticate with username & password to a password protected Artifactory repository?

UPDATE0: According to the Ivy documentation, the most likely realm name is simply "Artifactory Realm". According to the SBT documentation, the correct default location of the credentials file should be %USERPROFILE%/.sbt/.credentials (yes, I'm using Windows). Even after deleting the .credentials file in my .ivy2 directory it still doesn't work.

UPDATE1: Relevant but not actually helpful:

• SBT not passing credentials when publishing to Artifactory
• Sbt can't authorize in Artifactory

UPDATE2: I'm starting to suspect that this is a bug in sbt - I've added an issue here: https://github.com/sbt/sbt/issues/2817

Answer 1

See this question for details on how to configure global credentials.

To summarise:

If you need to boot SBT from a proxy repository, set the system property sbt.boot.credentials to point to your credentials file. You can do this in your %CSIDL_PROGRAM_FILESX86%/sbt/conf/sbtconfig.txt, for example:

-Dsbt.boot.credentials=/Users/my-user-name/.sbt/credentials

Alternatively you can use the SBT_CREDENTIALS environment variable for the same purpose.

For Artifactory, the realm in the credentials file should be set to:

realm=Artifactory Realm

For authenticating dependency artifact retrieval, create a file like %USERPROFILE%/.sbt/0.13/plugins/my-credentials.sbt with a credentials setting. For example:

credentials += Credentials(Path.userHome / ".sbt" / "credentials")

Answer 2

I think the default location for this file is ${HOME}/.sbt/<sbt-version>/.credentials; while I trust there is published documentation on this, I confirmed this by clicking around in the code.
@salim-fadhley, looks like you are missing the SBT version in the path.

EDIT: You need to add DefaultOptions.addCredentials to your build.sbt; you can then verify what SBT picks up with show credentials.

File location aside, there seems to be confusion between repository names (mean nothing) vs. security realms (mean everything).

The auth-challenge that comes back from the repository server will include the name of the security realm; as a client/developer, you have no control over what it is and my guess is it must match the realm you (client/developer) specify in your .credentials file (wherever that is).

Meanwhile, the repository name (as featured in build.sbt) actually means nothing to anyone outside development of the corresponding project e.g. the repository server admins could not care from one project to the next.