Multiple logins for Docker Hub

Features like teams and groups for DockerHub have been slow to get added and even slower for DockerCloud. This means multiple hub accounts - one for you as a developer and one for managing the repos of your workplace.

And you may often end up wondering:

How to use `docker login` to register multiple usernames so if one doesn't work for the repo you're trying to upload, it uses another one?

The answer is that its currently not possible!

If you look inside the config file (`cat ~/.docker/config.json`)
You will realize that `index.docker.io` corresponds to the key for your login to dockerhub and there isn't a clever way in the framework right now for it to distiguish between multiple usernames. That is to say the value of that key is not an array but just an object. In the future if we can get something like:
... notice the additional [] symbols indicating an array ... then there may be a possibility for such a feature.

There are references to alternative credential stores in the docs but it is not clear if such docker-credential-helpers understand multiple logins for the same site or not. Perhaps is would be best to setup teams and groups properly with permissions rather than focusing energy into managing multiple logins.

Flex Deep Linking and Server Side Redirects

With Flex its easy to:
a) use deep-linking (IBrowserManager & BrowserManager) to create application URLs that allow the use of the browser's backward & forward navigation buttons,
b) bookmarking a deep-linked URL and reloading it also works just fine

B U T ... what doesn't work is when you need to authenticate users before letting them access their bookmarked content. The reason behind this is simple ... the out-of-the-box javascript (history.js file) provided by the flex framework uses the # (pound/sharp) symbol to manage the deep link fragments. For ex:

1) http://www.hostname.com/application.swf#view=account
2) http://www.hostname.com/application.swf#view=profile
3) http://www.hostname.com/application.swf#edit=account
4) http://www.hostname.com/application.swf#edit=profile

Now according to the HTTP spec, the part after the # symbol is not sent over to the server in the HTTP request. This means that your server has no clue where to redirect the users after they successfully authenticate!

What can you do?

Workaround # 1:
1) Provide a bookmark button in the application itself and replace the # symbol with the ? symbol when storing the link.
2) Edit your client side to treat the ? symbol in the same way it treats the # symbol, therefore picking up the deep link fragments properly.

Workaround # 2:
1) Have your users manually edit their bookmarked links to replace the # symbol with the ? symbol.
2) Now that the deep link fragment is making it over to your server side as a URL parameter, edit your server side to replace the ? symbol with the # symbol when redirecting the user back to their bookmarked link. If you are using the spring-security framework then you can refer to the following blog as a reference on how to configure your application context's xml files properly.