Using containers for multiable identitys on websites

[lnee94]

How this would work.

• add option to select a set of containers to open a site in.
• when you go to example.com it should first open a landing page with an option set of which container to open in. (it should to have the option to use a list style or a grid style)
• Integration with password manager to set default login for a container. One way of doing this say add a data store where extensions can store anything in there (there would need to be a public for all extension and maby a private one too). and add a API that would allow extensions to set if a login shows as default. (NOTE this does not need to implemented for the other features to be useful it's just a nice to have)
• the ability to set the container icon to a data URI or a favicon.

What is the use case.
The main one I can think of is you have two accounts for one website loging out and loging in would suck and have to go to the extension is jank and out of the way so have a nice soft landing page for this perpus would make the usage experience for account hopping better then chrome.

[lnee94]

With this you could use the proxy containers extension to have the option to visit in tor or i2p or public

[lnee94]

Something that is also on the table is an option to not save history and an option to not save cookies (each option would not be linked, e.g. truth table would be 00 01 10 11) for a container

[kelimuttu]

Interesting! I can see how this can be useful for a heavy user of the multi-account-container feature. Maybe document this as a feature request?

[achernyakevich-sc]

@kelimuttu

It would be possible to achieve this if we will have implemented that we discuss in #2687 - user will need to add URL to some "default" container but do not confirm by ticking checkbox Remember my decision for this site. So every time he will be asked and will be able easily select container that should be used this particular time.

I think we could link discussions and move to that one.

[kelimuttu]

It seems that this one is more about bulk-action, though. I can imagine this is more useful for heavy-users with multiple accounts on a platform.

[NiklasBr]

more useful for heavy-users with multiple accounts on a platform.

It would help me, I have two accounts on BitBucket for two separate organisations:

• One accesses bitbucket.org/foo
• The other bitbucket.org/bar

Because the shared domain I cannot click the Remember my decision checkbox which is also very annoying because of how many tabs I need to open and close to work effectively. I ended up moving one org to another browser.

[kelimuttu]

@NiklasBr Makes total sense! Would you or @lnee94 open a new issue to document this as a feature request? Thanks!

[influential-eliot]

Not meaning to sound negative, as I think I'm very much for this idea ... but ... ... I think I already use MAC in this fashion with MAC + KeePassXC ... what am I missing that this provides already?

( given that it's not a good idea to keep passwords in any browser ... )

[achernyakevich-sc]

This is more about opening necessary container depending on the URL of services that support tenants/orgs and expose it in URL. For example GitHub:

• https://github.com/companyA/ - reference to GitHub organisation companyA that I need be logged in as UserA and would like to automatically open it in the container GitHubA.
• https://github.com/companyB/ - reference to GitHub organisation companyB that I need be logged in as UserB and would like to automatically open it in the container GitHubB.

AWS has similar but in the server name.

[aaribaud]

There is also the case of different containers, e.g. one for the admin user and one for a non-admin user, for exactly the same URL.

[influential-eliot]

Ah, OK, I have made my own way of dealing with this ... I utilise the redirector extension and effectively just make bookmarks for fake .local domains ... then I parameterise my subdomains with what I need to do to access a given thing.

I imagine that a cleaner version of this could be done utilising the @moz-document stuff ... making that relevant, again. :)

@moz-document [ <url>                    |
            url-prefix(<string>)     |
            domain(<string>)         |
            media-document(<string>) |
            regexp(<string>)
          ]# {
  <group-rule-body>
}

[s3r3n3ty]

TLDR: underlying functionality already exists, but UI is sub optimal + idea for a better UI flow

I switched to Firexfox just for this extension, expecting pretty much what op is after as well, being able to seamlessly switch between multiple accounts for a given site.

Now functionally this is absolutely possible, but the UI for this use case is terrible.

create container1 > open site in container1 > log into account1 > set to site to always open in container1 > create container2 > open site in container2 > log in to account2 > use 'repoen site in' to switch accounts > lots of site / account specific containers will now clutter the container menus.

Instead create a new option 'log in with other account'.
This will create a container that's only meant for a specific site and account and will not show as a general container, to reduce clutter in the container menus. (I currently have 15 account & site specific containers and it's getting rather cozy)
Or in other words, if a container is created through the 'log in with other account' option, that container will only show up as an option for that site (with an option to add other domains that use the same account)

open site > log into account1 > press 'log in with other account' in extension menu > log in with account2 > switch accounts (under the hood containers) by

1. clicking on the account name listed at the top of the extension menu with the account first logged into opening as default (opening the site in the container that was first used to log into the site) *
   OR as op already suggested
2. a landing page, with keyboard navigation (number keys instantly open respective accounts or arrow keys and enter)

account names are extracted when user logs in and set as container name by default, but are editabel by the user, in case the log in is an email or phone number instead of the actual user name)

As a bonus, at least for popular sites, profile pictures could be extracted with a formula, to be displayed next to the username for a quicker visual cue to the user.

Really hope this gets traction, since the underlying functionality is there. It's just the UI that needs to be improved.
If there's actual interest in this and I'm not just screaming into the void, I'd be glad to build a UI prototype to help make this a reality, since code is not my specialty.

*since simply logging into a site will not create an account specific container, clicking on the first account would open the general container that was used to first log into the site, but if for a given site there have been no log ins on any container yet, the option 'log in with other account' shows up as 'create container for login' (or something along those lines), while leaving the option functionally identical.

[LorDMyxYiz]

Aug 9th, was the last comment that I see here for this subject. It would be nice if the developers would correct this as people are screaming for this change. If the container names were kept in a nice tidy .json file instead of a .db file, this would not be an issue as a simple .py script would take care of this in an instant.

Sometimes this works for login to cpanel or hosting/email servers etc;, that use a port number like domain.com:3821/ but it depends on how they handle their session cookies or session id's.

In the mean time, there are 2 simple ways to accomplish this that will work.
This first one requires an extra step of effort but will work.

1. Make you container names.

2. Type a fake url in the address bar that you know will not resolve (nilbczcsieissiosi.com). That will open a server not found page blank page. Click the FMAC icon in the right side of the address bar for the drop down to select the container you want to use to always open that url in that container. When you select the container, that fake url will open in the new container that you just picked. Copy that fake url to notepad for later. You can close the container now.

3. Here is the fun part. Create a folder either in your bookmarks or on the bookmarks toolbar under the address bar (my fav). Name the folder (Ai, Social Media etc;) for the type site that you want multiple logins for. Create a folder in that folder for the "site" name, then two bookmarks in that folder. One for the fake url and one for the real login account. Name the bookmark "My login page-A" and another underneath with the real login page url named "My login page-B" (these are just examples). Now click the link for the fake url. A page will open in the container you chose. Now click the link to the real login-B page and it will open in the container you are in. Do not click the always use this container for the second one if it ask. Two clicks and you are in, and can have multiple accounts for the same site open in different containers. A lot of times, you can just close the container and when you open it again, you do not have to log in again. I would advise against this especially if you are in an environment where others have access to your computer. Remember, it is always best to click the fake url first.

The reason for doing step 1. with a url that doesn't resolve is that there are no cookies, trackers ect; to worry about or delete first. By doing it this way, you have a fresh page to log in.

Wash rinse repeat for the other named containers for other user accounts.

This is just two extra clicks, and you can open the same site in different containers.

The other way still takes one extra click but is cleaner and my favorite, but it may not be available on all sites. Note: I am surprised that this one is not discussed more. This involves the easiest of them all.

1. You have to know that you can create separate containers for the same url for subdomains (name.domain.com). The trick here is for that subdomain to have either a login link or a link back to the home page. If not, you are still on the site you want to be on and just use the first method and replace the fake url with one of the subdomain names. Either way you are golden.

2. I will use X.com as an example. You can look for links at the bottom of X.com or the site you want to do this with. Create a container name for your user name and use a subdomain ex: (about.x.com) as the page to open. After you open the page in the container, click the icon in the address bar and from the drop down, select the container you just named as the container to always open. Then just click the login or home button from there. Click, click done. Too easy. Then use a "different" X.com subdomain for your other accounts. If you are on Substack, then it is even easier as every account created comes with its own subdomain and a login link on that subdomain if you are not already logged in.

Feel free to spread this around. No need to reference me, just trying to help.

FYI. Fire Fox pw manager with Primary pw is you friend.

[drstonephd]

Background:

I have multiple firefox portable instances installed on a USB for various tasks. The wrapper exe only checks that any firefox is running, not for a firefox already using the same profile. Because of this one cannot open more than one profile at the same time and also be able to open a url for an open profile from a cmd. (You can add tabs manually.) To get around this I don't use the wrapper exe. I open the firefox.exe in the portable folder directly and point it at the profile folder for that instance. This allows keypass to open several profiles at the same time and add also add tabs to these profiles. The is the keypass url override I use is below.

cmd://"{REF:thisgetsthefirefoxexe}" -profile "{REF:thisgetstheprofilepath@...}" "{URL}"

Now for Containers:

The multi container works well for almost everything. The one place it does not work perfectly is with domains where I have more than one account. A profile per account would isolate the cookies, but that's too many profiles. A container does not have an easy way to associate a container to an account from just the domain url.

For example, opening two tabs from a cmd for my goggle email end up in the same container. I can't use /u/0/and /u/1 url stuff because they don't associate with the account, just which happened to be opened first. Even if it did work, it would be a goggle only solution. So, my urls for my two accounts look the same and both use the same container and share cookies. I have to logout to use the other.

https://mail.google.com/mail/u/0/#inbox (for workmail@gmail.com) -- not real addresses, btw
https://mail.google.com/mail/u/0/#inbox (for junkmail@gmail.com)

My first thought was to add a query to the url that goggle would ignore.

https://mail.google.com/mail/u/0/?mymulticontainerkey=workmail/#inbox
https://mail.google.com/mail/u/0/?mymulticontainerkey=junkmail/#inbox

I would have a deterministic way to open the container with the cookies associated with the email account. However, multi container does not have an option to look for a custom query. (A tag might work but is more risky because it's not ignored and depends upon how parsing it was implemented.)

I don't have any idea how you would know without metadata which "duplicate" container to use. The real url does not identify what I want. From keypass, all I can do is select profile and url. A few profiles is bad enough. One per account would be a night mare. So, the url is the only option?

Maybe firefox needs a new parameter. firefox -profile blah -account blah url ? The container is specific to profile, account, and domain? Yuck. Glad I'm retired.