Unable to use some special characters in Advanced Proxy settings

[IntinteDAO]

Multi Account Containers is a great project, but in my opinion it has one drawback related to Proxy, which is that there is no information about support for authorized Proxies.

Often Proxy servers have authentication by IP or Login/Password. While IP is not a problem because that is done by the Proxy server, in the case of Login and Password it is we who have to provide the authorization data.

IP, on the other hand, has one disadvantage - it makes movement impossible or difficult. We would have to change our IP information on the Proxy site with every change of address.

Authentication using Login and Password solves this problem. That's why I suggest adding a Proxy authentication option if possible.

[groovecoder]

Hi. The current proxy implementation supports authentication in the proxy url. E.g., https://<username>:<password>@<host>:<port> - does that work for you?

[IntinteDAO]

Hello.

Sadly no. The authorization data from the link is removed and only the connection type (HTTP in my case) and IP is left.

And I receive proxy auth popup to authenticate when try to connect using container with this proxy

[czettnersandor]

There's also a character limit in that field.

[IntinteDAO]

@czettnersandor

It seems to me that it's not a size limit problem, but a regexp problem that removes characters it thinks are inappropriate anyway.

[lhunath]

Can the character limit be lifted? I'm unsure why it would even be there. Oddly, the release notes state:

• Adds support for longer proxy urls

This may be in reference to https://github.com/mozilla/multi-account-containers/commit/26457f4c3f70f022cad14853e5743b7c7d1e2835 but the field is still character limited for me. See also https://github.com/mozilla/multi-account-containers/pull/2296, https://github.com/mozilla/multi-account-containers/issues/2364

[lhunath]

There may be another issue, potentially as indicated by @IntinteDAO, since adding a proxy URL such as:

• https://maarten.billemont:[sequence of a-zA-Z0-9]@[ip]:9090
• https://maarten.billemont@[ip]:9090

Caused the URL to get replaced by:

• https://maarten.billemont:undefined

[stillpointx]

Is there a way to use socks5 proxies? Example: socks5://Username:Password@ip_address:1080

[stillpointx]

There may be another issue, potentially as indicated by @IntinteDAO, since adding a proxy URL such as:

* `https://maarten.billemont:[sequence of a-zA-Z0-9]@[ip]:9090`

* `https://maarten.billemont@[ip]:9090`

Caused the URL to get replaced by:

* `https://maarten.billemont:undefined`

Yes, I get this trying to use a socks proxy example: I type in socks://username:password@ip_address:1080 and get socks://ip_address:undefined

[zigzagsui]

same problem. any solution for this ?

[stillpointx]

same problem. any solution for this ?

The problem has been open for about 6+ months they say it's fixed but have yet to push the fix out to the mozilla "add-on / extension server". They say they'll push it out "soonish", which after 6 months their timelines don't mean much to people anymore (they have had this issue reported multiple times in one way or another, they say it's fixed and close the issue but never push out the update). You would think they would fix login/password issues quickly but that doesn't seem to be the case, so don't hold your breath.

[grzegor]

This is just insane, it's now over 9 months to merge a trivial bug fix. Is there a reason why this is happening? It's almost like someone deliberately nerfed this to an unreasonable top character limit to sabotage anything except Mozilla VPN and now refuses to merge a fix. I know this is not a case, and I'm not accusing anyone of anything, but this is just so silly right now that it's hard to justify with anything more sane that this!

[dannycolin]

The limit has been lifted in the latest version (8.1.2). However, I was still able to reproduce the issue related to special characters in the username/password.

[joshuat]

If you install this extension, you can add proxies and then assign them to containers. I'd love for the existing functionality to work, but this works just as well until this issue is resolved.

[eiqnepm]

Hi. The current proxy implementation supports authentication in the proxy url. E.g., https://<username>:<password>@<host>:<port> - does that work for you?

I am unable to get this to work with Multi-Account Containers.

My connection string looks like this https://[a-zA-Z0-9]{24}:[a-Z 0-9]{24}@host:port.

When I save the connection string, the username and password is stripped from display in the UI (I can only assume it is not saved anywhere in the back end either), when I try to use the container, I am asked to enter a username and password for each session.