Manually add URL's to a container

[TriMoon]

• Multi-Account Containers Version: 6.2.3
• Operating System + Version: Kubuntu 19.10
• Firefox Version: Nightly Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0 ID:20200229214828

Other installed Add-ons + Version + Enabled/Disabled-Status (Click to expand/hide)

About Sync 0.0.51
Amazon.com 1.1
Authenticator 6.0.1
Awesome RSS 1.3.5
Bing 1.1
CanvasBlocker 1.1 [DISABLED]
Certainly Something (Certificate Viewer) 1.2.3
Compat Report 0.1.0
Containers theme 1.0.3 [DISABLED]
Context Plus 0.6.0
Debian queries 2.3
Decentraleyes 2.0.13
Disconnect 5.19.3 [DISABLED]
DuckDuckGo 1.0
DuckDuckGo Privacy Essentials 2019.12.12 [DISABLED]
Emoji Cheatsheet for GitHub, Basecamp etc. 2.0.1
Enhancer for YouTube™ 2.0.99
Enterprise Policy Generator 5.1.0 [DISABLED]
Feedbro 4.0.3
Firefox DevTools ADB Extension 0.0.5
Firefox Lightbeam 2.1.0
Firefox Multi-Account Containers 6.2.3
FoxyProxy Standard 7.4.3
Google 1.0
Greasemonkey 4.9
HTTP/2 Indicator 3.0
IPFS Companion 2.10.0
Laboratory 3.0.7 [DISABLED]
MathML Font Settings 0.3.2
Native MathML 1.9.4
Nightly Tester Tools 4.0
Notes by Firefox 4.3.5 [DISABLED]
Offline QR Code Generator 1.6
PassFF 1.9.1 [DISABLED]
Plasma Integration 1.7
ProtonDB for Steam 1.6.0
React Developer Tools 4.4.0 [DISABLED]
Session Sync 3.1.12
Snooze Tabs 1.1.1
Tab Session Manager 5.2.0 [DISABLED]
To Google Translate 4.0.6
Tree Style Tab 3.3.6
True Sight 1.7.1
Twitter 1.0
Vue.js devtools 5.3.3
Wikipedia (en) 1.0
YouTube Container 1.3.0
eBay 1.0
uMatrix 1.4.0

Actual behavior

No way to add redirecting URL's.

• If you DON'T FORGET TO DO THIS EVERY TIME:
  • Only way at moment is to use right-click and choose a container.
  • Else you are screwed...

Expected behavior

To automatically open known redirect URI's we need a EASY way to add them to a container.
Sometimes you want to catch redirect links, to force them to always open in a certain container before the browser navigates to the destination of the link.
For this purpose we NEED a way to manually add URL's to a container of choice !

Steps to reproduce

1. Try to add a rule using the UI for links like https://go.microsoft.com/fwlink/?LinkID=xxxxx&wt.mc_id=fuckmedead
2. Stuck because there is no way.
3. Write bug report on github, like i do now 😉

Notes

Related issues: #719, #837, #839, #1057, #1075, #1180, #1335, #1317 and maybe many more im tired search now...

[fprochazka]

Yes please, this would make the extension amazing!

I want to be able to add amazon iam-account login links to containers, but they are redirects, which means there is no moment to intercept it and add as "always open" in a selected container.

This would allow me to:

setup:

• create new AWS IAM user, store the login link (which has account ID in its url) and login credentials to LastPass
• create a new Firefox Container for that AWS account, add the login link as always open in this container

usage:

• open LastPass window, search for the AWS account I want to log into, click the item
• LastPass opens the login link
• Firefox Containers intercepts the link and opens it appropriate container (to prevent login conflicts)
• LastPass fills in login credentials
• I submit the login form and I'm in the correct AWS account

[sherry13131]

Hi @kendallcorner, can you assign this issue to me?

[AdamJel]

Further to this:
The settings of 'limit to designated sites' in NOT currently synced. The site list is, but it is needed to tick the box again on new instance of Firefox. It would be very useful to synchronize this as well.
And I support the idea of having option to import/export/ settings = managing it by file, which may then be on a repo and thus having the ability to declaratively set the state. I already have quite a number of containers, so having the option to manage it by script (json) and having it backed-up on git would be nice.

[B00ze64]

I believe this would be better served by being added to Firefox, on the Options page, rather than in the tiny extension pop-up menus. This way we can have a large text box that we can edit and copy/paste into. This would also make moving container assignment to new profiles a matter of copy/pasting.

[AdamJel]

I believe this would be better served by being added to Firefox, on the Options page, rather than in the tiny extension pop-up menus. This way we can have a large text box that we can edit and copy/paste into. This would also make moving container assignment to new profiles a matter of copy/pasting.

Imagine you have 100+ containers. Then the matter of copy/pasting is not a pleasant option. On the other hand, one text file, beiing yaml, json or whatever, is easy enough.

And these two options dont exclude one another. It may be, that the window for copy pasting is just a gui for that text file.

For me, it would be extreamly pleasant to have just one descriptive text file and option to point extension to that file to load and set all containers, site lists included.

[B00ze64]

I agree with you. Never occurred to me someone would have that many containers lol, but of course Export/Import would be awesome. Right now settings are stored in IndexedDB. You can move that around (storage folder,) but because of ID's etc, it will probably not work in another profile. I still would appreciate a nice textbox, preferably in the options, where I can quickly add and remove stuff from within the browser, by just typing domains, and copy/paste stuff between containers etc. But if Import/Export uses yaml, json or whatnot that will do fine, we can edit that easily enough!

[jeremymeyers]

https://addons.mozilla.org/en-US/firefox/addon/simple-tab-groups/ handles this pretty well, and you can use a regex string too.

[EDIT to fix url]

[xdhmoore]

@jeremymeyers I think your link got wrong-linked...

[jeremymeyers]

@xdhmoore my bad. fixed now.

[hmlendea]

I am struggling with this because of redirects... It would be awesome if we could do it, as well as allowing wildards such as *.aliexpress.com

[grahamperrin]

#839

@TriMoon we have triplication of issues. Please, can you close this one? Leaving the automated cross-references in the earlier issues. Thank you.

[Korb]

I have mistakenly posted a similar proposal to bugzilla.mozilla.org. The full text can be read at the link I gave. In general, I support the proposal to add the ability to add dozens and hundreds of domains with all subdomains to containers in the same way as it is done with custom filters in ad blockers.

[comrademmirg]

I'm surprise to find this isn't a feature, could have a simple check box "always open this site in this container". Seriously, who on earth would want to manually select containers every time they open a new tab?

[mc0e]

Why has this been waiting so long? IT doesn't sound like there's disagreement with the proposal, and @sherry13131 offered to work on it.

[TriMoon]

#839

@TriMoon we have triplication of issues. Please, can you close this one? Leaving the automated cross-references in the earlier issues. Thank you.

There is a reason why issues stay open, even if duplicates exist.
(In which case it shows how wanted it is)

So I politely decline your request 😉

[kurahaupo]

@TriMoon
I desperately need this feature myself, but forking the commentary among many issues actually hurts rather than promotes it.

I can tell you from experience working on other projects that have many live bugs referring to the same underlying problem is TERRIBLE; it saps time and energy just dealing with bug triaging, leaving less and less time to work on fixing it.

If you want to make a bug more likely to be worked on, make it easier for prospective fixers to deal with the reports: add your comments to the existing bug, don't create new ones. Or if you have some variation that you think warrants a separate issue, and put detailed cross notes with the reference in the main issue, so that the coder who works on fixing it can see whether it's worthwhile reading the other bug to get some detail.

One bug report or feature request with 100 comments will be much more likely to get fixed that 3 bug reports with 33 comments each. And 3 bug reports with 100 comments are just going to annoy the fixer for wasting their time.

If it's so important to you that it transcends normal etiquette and good manners when dealing with volunteers, consider volunteering yourself to fix it.

[kurahaupo]

I note that issue #1833 is currently pinned, so it's much more likely to receive attention than any of these related bugs.

[kurahaupo]

I note that @sherry13131 did work on it and appears to have, if not a complete solution, at least a step in the right direction. However the PR has gone stale for 16 months and so I've rebased it against today's master and re-submitted it as PR #2114.

[sshquack]

Please provide this functionality to manually add a URL to a container. Here is my config:

• Firefox 95.0 (64-bit)
• MAC 8.0.3
• macOS monterey 12.0.1 on M1

[MadManMoon]

Additional Vote For Functionality

I also would absolutely like this functionality.

FF 99 Nightly
Win 10, Linux (i know) - Latest

I would also suggest the ability for other add-ons to address this one simply via API. So that programs such as firewalls, or script blockers like noscript, can assist in management of sites, and provide even deeper sandboxing of scripts and more per container.

---

The IndexedDB Database

Where is this IndexedDB file, and can I easily edit it in DB Browser (SQLite) or something? (as a scrappy workaround) I've had a look around (including the XPI) and can't find anything obvious.

Also, I have what I would've thought as more containers than most. Were 'ABE' still a thing in noscript (it will be again), I'd wholly like to have that and containers fully syncopatio.

I agree with you. Never occurred to me someone would have that many containers lol, but of course Export/Import would be awesome. Right now settings are stored in IndexedDB.

[mc0e]

Never occurred to me someone would have that many containers

The only reason I don't have hundreds of site specific containers is because of the awkwardness of the interface for making them work. This issue is a prime example.

I'd love it if I could have site-specific containers be the default, and created automatically, though I'm sure there would be many issues to work through.

[Zuccace]

Manually adding hosts would surely help, but as I just added yet another site to its own container, I encountered another problem: even if I gradually increased the redirect limit I seemed to miss one domain. I eventually brought up the inspector and from there opened a site in a new tab (with 0 redirect on). From there it was easy to add that domain to the correct container.
So there seem to be some javascript redirects on some sites that don't adhere to the (temporarily set) no-redirects setting.

The solution would be to have something to track which domains a tab has connected, then select and add sites from that list to the container.

[E14]

Manually adding hosts would surely help, but as I just added yet another site to its own container, I encountered another problem: even if I gradually increased the redirect limit I seemed to miss one domain. I eventually brought up the inspector and from there opened a site in a new tab (with 0 redirect on). From there it was easy to add that domain to the correct container. So there seem to be some javascript redirects on some sites that don't adhere to the (temporarily set) no-redirects setting.

The solution would be to have something to track which domains a tab has connected, then select and add sites from that list to the container.

The problem with those redirects is due to automated redirects to a domain that is (automatically) opened with a different container. That sounds to me like a security issue anyway, so FF (or the extension) should either ask the user what to do, with an option to add it to the current container, or just open it in the current container.

There is still an issue with javascript or meta forwards, but at least those are delayed somewhat and the user should be able to see the domain in between; Though if it's possible to catch those, I would do that as well.

---

For a workaround, I found it easier using the dev tools network tab. If you enable "persist logs" setting (in cogwheel dropdown), you will also see page redirects, this may be a bit easier to check than playing with redirect-limit.

For example if you go to http://google.com you'll get

301 GET google.com
200 GET www.google.com

Now if you're trying to add a new container, just do a full login cycle in a private browsing session (with dev tab open and logs persisting), then filter out all the gunk (images, css, js, xhr, ...) and you'll end up with a list of all domains involved.

[Zuccace]

The problem with those redirects is due to automated redirects to a domain that is (automatically) opened with a different container. That sounds to me like a security issue anyway, so FF (or the extension) should either ask the user what to do, with an option to add it to the current container, or just open it in the current container.

Containers leaking data is a security issue.

[influential-eliot]

Agreed 100% !
@Zuccace said:

Containers leaking data is a security issue.

... ... although I could've sworn I saw Firefox handle the 'login' part of all of this automatically the other day.

Basically, I was in one container, it opened the login in another, then closed that and refreshed the original to finish the login process.

So it's possible that Moz are in the midst of handling the 'login flow over a different domain' thing which is a part of this multi-faceted request.

[E14]

Containers leaking data is a security issue.

Agreed, but containers and MAC in particular seem to be going the tab groups route from the core team support I'm seeing here.

Basically, I was in one container, it opened the login in another, then closed that and refreshed the original to finish the login process.

Maybe you were previously logged-in in the origin container and just authorized the app? Logins need to set cookies and those definitely should not be shared across containers, that's the whole point

[enikkari]

Easy workaround to manually add a redirecting url:

1. disconnect internet / wifi
2. put in url bar the url & hit enter
3. site is of course not found or redirected, add to container
4. Reconnect internet, done :D

I used this to add manually my different AWS accounts to the multi account containers. Or any other link where the url redirects
https://account-id.signin.aws.amazon.com/console

edit: I posted this workaround to help others since it took me some hours to figure out a way to do this and I thought it could help others. It seems this comment has rubbed some people the wrong way. It was not my intention in any way to hurt or annoy anyone, only to help others like me that stumble onto this message thread.

[influential-eliot]

Very helpful, but this is obviously not a reason to close this.

@enikkari said:

Easy workaround to manually add a redirecting url:

disconnect internet / wifi
put in url bar the url & hit enter
site is of course not found or redirected, add to container
Reconnect internet, done :D

I used this to add manually my different AWS accounts to the multi account containers. Or any other link where the url redirects
https://.signin.aws.amazon.com/console

[kurahaupo]

@enikkari It's a good option for those who can do that, but "shutting off the internet connection" is unreasonable where it would disrupt persistent connections such as ssh or irc. A more targetted approach that only blocks new TCP connections would be preferable. One way to do this on Linux is using iptables. To start blocking use:

sudo iptables -I OUTPUT ! -o lo -p tcp --syn -j REJECT --reject-with icmp-admin-prohibited

To unblock change -I to -D:

sudo iptables -D OUTPUT ! -o lo -p tcp --syn -j REJECT --reject-with icmp-admin-prohibited

You can use -j DROP instead of -j REJECT --reject-with icmp-admin-prohibited, but it'll be much slower, as Firefox will have to wait for each connection attempt to time out.

The ! -o lo means don't block loopback traffic, since there are undoubtedly local activities you don't want to disrupt.

[svenjacobs]

I tried to add docs.google.com to a container but it was always redirecting to accounts.google.com. I had to use the network.http.redirection-limit trick to be able to assign this domain to a container. That workaround shouldn't be necessary. Manually adding a site to a container or editing a site list would be greatly appreciated 🙏🏼

[jhard]

Also affected by this issue, I might have a workaround that's easier.
When you confirm adding a site to a specific container's config, that confirmation page's URL will be similar to moz-extension://c1e32a09-c7fd-4fcb-94d2-fa7ff73ecf64/confirm-page.html?url=https%3A%2F%2Fexample.com&cookieStoreId=firefox-container-123

You can replace the URL (and cookieStoreId) with whatever you want to include, and then confirm that, and it will be added correctly.

[influential-eliot]

Interesting, @jhard, thanks!

Also affected by this issue, I might have a workaround that's easier. When you confirm adding a site to a specific container's config, that confirmation page's URL will be similar to moz-extension://c1e32a09-c7fd-4fcb-94d2-fa7ff73ecf64/confirm-page.html?url=https%3A%2F%2Fexample.com&cookieStoreId=firefox-container-123

You can replace the URL (and cookieStoreId) with whatever you want to include, and then confirm that, and it will be added correctly.

So, we'd just then need to know the container ID, one would assume. Plus to be cognisant of domain/subdomain stuff, of course.

I wonder how easy it might be to use a userscript to work around/with this.

[kurahaupo]

That almost sounds like I could hijack the "choose search engine" facility, since that is mostly just "paste the search term into the middle of this custom URL".

[Holbormon]

Also affected by this issue, I might have a workaround that's easier. When you confirm adding a site to a specific container's config, that confirmation page's URL will be similar to moz-extension://c1e32a09-c7fd-4fcb-94d2-fa7ff73ecf64/confirm-page.html?url=https%3A%2F%2Fexample.com&cookieStoreId=firefox-container-123

You can replace the URL (and cookieStoreId) with whatever you want to include, and then confirm that, and it will be added correctly.

Interesting workaround. Unfortunately, it doesn't work in the specific case of two URLs under the same domain. Here is an example:

I want to use the custom URL https://outlook.office365.com/mail/?login_hint=example1@example.com to assign Outlook's login page with a specific e-mail account (here example1@example.com) to a specific container. Since I have two containers and two e-mail addresses, I tried the above, but both URLs still open in one container: the last one I try the workaround on always prevails.

[kurahaupo]

@Holbormon that is not a shortcoming in this plug-in; it's by design in the core of Firefox.

The core container mechanism in Firefox only consults the domain (aka "site"), and so when you ask any plug-in (this one included) to add a URL to a container, it necessarily has everything but the domain stripped from it.

For the level of separation you desire, perhaps consider running multiple Firefox profiles.

[repsejnworb]

Why is this not in yet?

This plugin loses soo much value without this, with all the redirect shenanigans on the internet..
Manual adding and wildcards.. pleae.

[xanoni]

Why is this not in yet?

Because this is open source and nobody has sent a PR, yet, haha.

But otherwise, I agree. I've been watching this issue for years and don't even understand if this is difficult to implement. So same question.

[lonix1]

In prioritising new work, it may be helpful to consider that this issue is currently the fourth largest pain point for users, which is not blocked by upstream issues ("Needs: Mozilla Central").

[dannycolin]

which is not blocked by upstream issues ("Needs: Mozilla Central").

It doesn't mean that the level of complexity is less important. When you deal with URLs, you need to validate the format of them. This includes validating the TLD of the domain which currently isn't possible without a third-party library (Public Suffix List). There's been discussions in the WECG to add a new webextension API so we can call the version already available in all browsers and avoid privacy/security issues that comes with using our own copy of the PSL.

Another pain point is dealing with URL parameters, paths and fragments. This can easily lead in a situation where the elements added by the user creates an unwanted behaviour (e.g. infinite loop between containers). Users are going to blame the extension for not handling it properly instead of them not understanding that their URL is the problem. To me, this means we can't simply add a input field with an add button and hope for the best. There need to be some UX work done in that regards before writing code. We also need test coverage for all that and contributors often ghost us when it comes the time to write tests.

In other word, this isn't a good first bug type of bug. We'd need someone that is comfortable with the different concepts involved. I'll be more than happy to discuss it in a 1:1 if that someone wants to contribute.

[eternal-sorrow]

Another pain point is dealing with URL parameters, paths and fragments

Does the extension even support adding specific URLs to a container? I thought it's only domains.

[eternal-sorrow]

Support for parameters, paths and fragments can be a later improvement, or the user can rely on the workarounds mentioned above.

Again, right now there is no support for "parameters, paths and fragments" with or without workarounds. And frankly, it's not needed. And it's 100% not what this issue is about.

[dannycolin]

Maybe a compromise can be reached in the short term, where the manual addition feature only allows adding TLDs (and subdomains).

We can't validate the TLD at the moment if it's manually added without w3c/webextensions#231.

We could naively use https://developer.mozilla.org/en-US/docs/Web/API/URL/ for the hostname, params, etc. However, the issue I mentioned wouldn't be solved.

@groovecoder I'm not comfortable adding this feature as something we officially support without PSL but I'll be open to accept a patch that adds an experimental section in the option page (similar to Firefox Labs) for it. What do you think about it? Would it be an acceptable compromise?

[kurahaupo]

@dannycolin I understand that this necessary to validate the structure of a URL, but why does that imply needing to know which domains are currently reachable?

What constitutes a "valid" top level domains depends on the user, and can change dynamically. We all start with the public set managed by ICANN, but it's very common to add a domain for a LAN (DHCP, autoconf, etc), or for tunnels such as TOR. We can also add and remove domains for local policy reasons.

Surely if a domain is not reachable, it does not matter which container is used to open it?

(And of course, using an IP address as the "hostname" means there is no "top level domain", since the structural "top" is on the left rather than the right.)

[tsbertalan]

Yeah, I don't see why it would be necessary to verify the content of a manually added domain. If the rule doesn't work, that's my fault; don't help me unnecessarily. I and many power users would probably prefer to be able to provide arbitrary URL regexes, but I can easily imagine that the implementation is tied in a low level that only sees the domain.

…

________________________________ From: Martin Kealey ***@***.***> Sent: Friday, October 11, 2024 7:45 AM To: mozilla/multi-account-containers ***@***.***> Cc: Tom Bertalan ***@***.***>; Manual ***@***.***> Subject: Re: [mozilla/multi-account-containers] Manually add URL's to a container (#1670) @dannycolin<https://github.com/dannycolin> I understand that this necessary to validate the structure of a URL, but why does that imply needing to know which domains are currently reachable? The list of valid top level domains can change dynamically, with the list comprising the "shared" public set managed by ICANN, plus domains provided by local ethernet domains (DHCP, autoconf, etc), by VPNs, by TOR, by static interface configuration, and simply by user tweaking. Surely if a domain is not reachable, it does not matter which container is used to open it? — Reply to this email directly, view it on GitHub<#1670 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AACKXWNU5WDZHKA5RETUGELZ2624PAVCNFSM4K7FHF62U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBQG4ZDGOJXGE3Q>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[krokofant]

Yes please to experimental support, and TIL Firefox Labs! Would be great to have something to try out and evaluate rather than the user injecting custom code to workaround this.

[itsbetterhere]

Why is this a four year old enhancement? This seems like a basic feature that should have been included at the very beginning. All the comments as to why it hasn't been added seem to be related to underlying specifics that you don't give us access to anyways. However, it seems like you could add those details after the fact by going through the same code that you do when I pick "open this site in container x". The only extra step would be for your plugin to open the domain/url on my behalf in the first place. Then do whatever it is you normally do under the hood. It's just incredibly disappointing that this wasn't a requirement for the initial release. Please just add this.

[kurahaupo]

@itsbetterhere As a fellow FMAC user, I feel the same frustration, but...

There have been some attempted patches, but none have been accepted. My understanding is that this is mostly down to the lack of available volunteer time to vet proposals, much less mentor the contributors on how to improve them.

Like any large volunteer project, Mozilla needs to be very careful about which patches they accept, since there's a strong likelihood that the person submitting it won't be sticking around to maintain it.

For me, my main obstacle is understanding the development environment. I can read code, understand it, and make changes, but I haven't a clue how to get code from github running inside my browser so I can test it.

I find myself getting immensely frustrated with "starter" guides that assume you're starting a new project, rather than trying to take over an old one, and fail to give any detail of the objectives along the way.

Worse, "standard procedures" have often changed since the project started, so the guides tell you to do things that outright conflict with what's already there.

It's really demoralizing. And I'm guessing that's why there are too few volunteers.