Community
Participate
Working Groups
The current mechanism for obtaining authentication information (credentials) from a user and storing them in secure storage limits the possibilities for those that require something else than basic authentication, and association of multiple credentials for the same host. There are several problems with the current "API": - there is no differentiation between different authentication schemes, basic authentication is assumed. This information needs to come from the transport level (possibly passed in the exception). - there is no selection of user interface based on authentication scheme - a user interface that returns username/password is assumed. - the storing of credentials also assumes basic authentication - as the user interface potentially reveals sensitive information, it would be good if trust could be established - now it just obtains an OSGi service. - work is needed to pass different types of authentication information to the transport layer and ECF. - currently the authentication information is stored for the "host" - those that need different passwords for different schemes, and different passwords for different paths have no way of entering such information (except entering each new password as required - cache/store is of little value here). I have marked this for 3.6 as this relates both to API, is an enhancement, and a change that ripples through several layers
Henrik, do you still have plan to address this as part of 3.6?
(In reply to comment #1) > Henrik, do you still have plan to address this as part of 3.6? No. Has not seen any questions relating to this, or demand for anything else besides basic authentication either, so I am making this a WON'T FIX.
