Comment 1 Steffen Pingel 2011-12-23 08:49:08 EST

I'll limit the scope of this bug to password prompting. I have opened bug 367493 to track certificate authentication.

Comment 2 Shawn Minto 2012-01-12 13:07:55 EST

When doing this, could you consider adding better support to subclassing the locations and location factories and re-using the password prompting if the classes are subclassed.

Comment 3 Steffen Pingel 2012-01-12 15:56:31 EST

The repository location classes are intended to be sub-classed. The credentials handling is delegated to the location service which can be set on a location. It's now injected through an extension point so in most cases location factories should no longer be needed. What is the use-case you had in mind for overriding the location factory behavior?

Comment 4 Shawn Minto 2012-01-12 16:04:27 EST

The case that I had in mind is when there is a 401 (http authenication required) but the user should be prompted for repository credentials instead of http authentication credentials.  The basic case is that the http auth and repository credentials should be kept in sync.

Comment 5 Steffen Pingel 2012-01-12 16:25:18 EST

Can you file a bug for that? I think it makes sense to handle that case in the HTTP layer. It's common enough that we should add a simple API for it.

Comment 6 Steffen Pingel 2012-01-14 08:16:35 EST

Support for having repository and http authentication credentials the same is tracked on bug 368568. 

I have pushed the changes for this bug to master. The supported authentication types that are defined as constants in AuthenticationType now specify the associated credentials class. We now have support for these types built-in:

* Repository (username/password)
* HTTP (username/password)
* Proxy (username/password)
* OpenId

This includes configuration UI through the repository property pages and (password) prompting. Support for certificate authentication is work in progress and tracked on bug 367493.