-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Root domain or domain template in the Site List #1833
Comments
+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 |
+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? |
containerise supports wildcards domains, as trash.fuckgoogle.com. Although it does not have some functions of this extension, he can at least do that |
Some overlap with 2017 issue #839 |
From opening post #1833 (comment):
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:
If you like, test the extension with this Either:
The extension should intercept, and offer a choice of containers. After the page loads, there'll be redirection to a page at the |
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.
In particular I note the connection with requests #640, #691, #719, #837, #839, #1057, #1075, #1180, #1227, #1317, #1335, #1501, #1670, #1688, #1784, 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. |
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?? |
I have been waiting for years for this feature, is there a technical reason why it can't be implemented? |
@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. :) |
@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. :( |
The OP on that issue even says "Something like Firefox Multi-Account Containers has." And MAC does had this feature for months now, it's called "Limit to Designated Sites". |
Looks like I have missed this feature. :) But in this case more correct will be pushing Containerise developer to implement black list support in addition to white list they have implemented. |
I'm surpised no one mentioned it before but this seems a duplicate of #473. :) We're also actively working on a PR that'd support this basic use case of Also, for more advanced use cases, we have #691 to support complexe patterns. I'll close this issue and invite all of you to upvote the issues I just mentioned. |
@dannycolin this issue was pinned and so had discussion on several related issues. If this issue is closed, we lose sight of the connection between these issues, and in particular lose track of the fact that wildcards (or subdomains) only solve some of them. In particular, the last linked PR does not solve the problem with websites that perform redirection when they require authentication getting stuck in an endless loop. (See notes above for fuller explanation.) This would be addressed by #839 so is there any chance that that issue might be pinned in place of this one? |
@kurahaupo The issue related to redirection has also been mentioned on #839 so we haven't lose sight of it. If there's any other issue that aren't already addressed by another bug report, please feel free to open a new bug report. This is a better solution than having suggestions buried in a thread like this one. |
Potential workaround by forcing a |
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.
The text was updated successfully, but these errors were encountered: