Root domain or domain template in the Site List

[emuzychenko]

The "Always open this site in..." function always adds the entire domain of the current URL to the Site List. In many cases, only the root domain should be added instead.

For example, I wanted to open all Live Journal blogs in the same container to keep my session authorization. Each blog has the ".livejournal.com" domain name in the URL. If I add my own blog (emuzychenko.livejournal.com) to the Site List, using the "Open Link in New ... tab" function with any other LJ user opens the new tab with no container. Default container for the root domain is not available.

I wanted to open any *.livejournal.com URL in the appropriate container. Maybe adding the root domain to the Site List would be enough, but I unable to do that. If I try to open livejournal.com, it redirects to www.livejournal.com, and there is no way to correct domain name before adding it to Site List.

The same problem occurs with some other sites (docs.microsoft.com, msdn.microsoft.com etc.) that share cookies for the logon session.

The simplest way to solve the problem is to add the ability to edit the domain name before/after adding it to the Site List, and allow a kind of template (*.livejournal.com) to be added to the Site List.

I use FireFox 78.0.2 ESR and Multi-Account Containers 7.0.2.

[RasmusMalver]

+1. I want to reserve the Google container to Google products, but that breaks the Google calendar, because it requires scripts from hundreds of *.google.com-domains. E.g. people-pa.clients6.google.com

[ChrisTheCat]

+1 this would be great. It's frustrating that I have to add all the variants (for example) for the nytimes - cooking.nytimes.com, www.nytimes.com, nytimes.com... and on and on. I would really like to be able to add *.nytimes.com.

Why isn't the domain list an editable text file?

[fabianski7]

containerise supports wildcards domains, as trash.fuckgoogle.com. Although it does not have some functions of this extension, he can at least do that

[grahamperrin]

Some overlap with 2017 issue #839

[grahamperrin]

From opening post #1833 (comment):

… no container. … any *.livejournal.com URL in the appropriate container. … livejournal.com, …

https://livejournal.com/ with Always In Container:

It's not a panacea – it can not add a domain to a Multi-Account Containers site list – however:

• it can prevent the no container scenario
• it should help you to open URLs in appropriate containers.

If you like, test the extension with this man.freebsd.org address:

• https://man.freebsd.org/hier(7)

Either:

1. use the link context menu to attempt no container for the link; or
2. open the link in a new window.

The extension should intercept, and offer a choice of containers.

After the page loads, there'll be redirection to a page at the www.freebsd.org site.

---

tiansh/always-in-container#6

[kurahaupo]

Since this issue is pinned, I'll note that it seems to highlight the same underlying limitation that has given rise a very large number of similar requests:

You can't add a domain without first loading a page from that domain.

1. Having to load the first page from a domain without container protection exposes the user in the very way that containers are intended to prevent. We need a more prophylactic process, ideally allowing pattern matching.
2. Having to load a page and then add the domain is quite slow and cumbersome when dealing with a large number of related domains. We need a bulk handling process.
3. Pages may include components in domains outside the container, particularly JS. Without using the "Network" inspector in the Developer Tools, this can be quite hard to find. We need still need "open this page in container", but it should offer all the domains connected to this page, not just the top-level one.
4. Pages may redirect through a domain outside the container, and it's not possible to get a stable page load in the other domain, there's no opportunity to add its domain to any container.
5. Because of this, Limit to Designated Sites is almost useless. When the user lands on a page that requires an authenticated session, it may redirect to another page to get the user to log in, and then redirect back.
   When those two pages are not in the same container, this results in an endless loop.
   This is particularly problem with larger service providers with many services. For example, Google has google.something and youtube.something registered in most top-level domains (hundreds), and more than 50 subdomains for products, each of which redirects to an account. subdomain (usually but not always in .com) when it requires authentication.

In particular I note the connection with requests #640, #691, #719, #837, #839, #1057, #1075, #1180, #1227, #1317, #1335, #1501, #1670, #1688, #1784, #1833, #1991.

Of these, issue #839 seems to have become a nexus issue to which many others are related.

It is particularly disappointing that a PR for #1670 has now languished for 16 months.

PS: You can in most cases simply load a nonexistent page from the domain, but in some cases that will result in a redirection.

[nylimited]

I only installed the multi-accunt containers addon yesterday and took me no time at all to find this problem. Lots and lots of sites use multiple servers, espcially banks, and they all miss the container my login page was opened in.

Why on earth is such a simple issue still here, looked at by nobody, after all this time??

[domigi]

I have been waiting for years for this feature, is there a technical reason why it can't be implemented?
As it is a pinned issue I am optimistic that it should be getting the attention it deserves.

[achernyakevich-sc]

@emuzychenko I quite carefully track this repo's issues and have found several that have the same problem that you described in your issue. My tracking make me feel that MAC developers will never implement this "quite complicated" because their goal is containers but everything else could be implemented by somebody else in their add-ons as MAC itslef provide great capability for integration (integration with Simple Tab Groups could used as a sample).

In my everyday life I have exactly the same scenario as you initially described. I have resolved it by installing and using of Containerise add-on. It feet perfect for your scenario. So I would like to propose you to try.

As well if it will resolve your issue them probably it would have a reason to close this one and this way show other users that Containerise add-on really helps. :)

[krisu5]

@achernyakevich-sc But Containerise has this issue instead: kintesh/containerise#172

[achernyakevich-sc]

@achernyakevich-sc But Containerise has this issue instead: kintesh/containerise#172

I have checked the issue you point to. It looks that you search functionality that never was implemented in both add-ons. Both of these use positive matching approach for opening matching URL in certain container. No one of them has anything about prohibition of opening URL in some container. So you case just do not match expectation of both add-ons.

I'm afraid that this will be never implemented by add-ons developers as not matching their vision. :(