Description Carsten Reckord 2016-02-23 15:01:26 EST

Working on bug 458573, I am struggling a bit with the way authentication is handled in the USS API, mostly due to its implicit / transparent handling. It would be great to also support a more explicit API for authentication and login management.

My use-case is this: We are using USS in the Marketplace client to store and change user favorites for the Marketplace. If the user is logged into USS, they should see which entries they have favorited and be able to toggle the favorite state. If they are not logged in, the favorite button ("star") will trigger authentication in order to change the favorite state. If the user logs in (or out), items need to be refreshed in order to show their actual favorite state (or reset it to "unknown" respectively).

I got this kind of working right now, but I'm relying on some very ugly hacks, including accessing the StorageService's current credentials through internal API and switching the ICredentialsProvider back and forth between ICredentialsProvider.CANCEL and the service's default credentials provider. The following would be very helpful to get this mess cleaned up:

1. API to trigger authentication explicitly (I'm currently doing an extra IBlob retrieval just to log in)
2. API to get the authenticated user's name (e.g. to show in an account widget)
3. Listener support on the service's authenticated user (i.e. notify me whenever the stored username changes and whenever authentication succeeds or fails)
4. Dedicated exceptions for authentication failures: clients should be able to easily discern between auth issues and "real errors" like communication problems. Auth issues currently seem to fall into two categories:
a) credentials provider returns null: an unchecked OperationCancelledException is thrown
b) authentication ultimately fails (authentication attempts exceeded): a generic ProtocolException with a HTTP error code of 401 is thrown

4 is admittedly a bit of gold-plating, but ideally 4a) and 4b) would throw exceptions with a common superclass, which could also be a subclass of ProtocolException. That way, they can be handled with a dedicated catch and one wouldn't need to rely on HTTP codes. At the very least, documentation should be added for 4a) on the affected IBlob methods - I didn't really expect it and only found out through trial and error.

Sorry for the multiple feature requests in one bug. At least between 1-3, I wasn't sure where a split into separate bugs would make the most sense from a technical standpoint.