GNOME Bugzilla – Bug 646354
Network proxy has no proxy authorization
Last modified: 2021-06-09 16:28:45 UTC
Created attachment 184794 [details] picture for network proxy setting -Network proxy comes without proxy authorization (username + password + domain) -There is no option that let the user use the same proxy for all protocol please fix this problem especially the first one
Can't you just use the standard proxy format, e.g. username:password@server:port
For me it is ok But for others especially noobs
We also have the same problem. we are in a university and they use windows server IIS, and its require to enter the name of the domain in the proxy configuration.. so please make these configuration, at least as advance
(In reply to comment #3) > We also have the same problem. > we are in a university and they use windows server IIS, and its require to > enter the name of the domain in the proxy configuration.. > so please make these configuration, at least as advance Can't you just use the standard proxy format, e.g. username:password@server:port I guess there needs to be something in the docs or as a tooltip for this.
I think this needs to be fixed/implemented rather than to be worked around via other means. Wouldn't you agree? Besides, passing certain metacharacters in the proxy host field might not fly well... (if that's what you were referring to, not http_proxy or other environment variables).
Would be also nice to see it stored in the gnome keystore.
(In reply to comment #5) > I think this needs to be fixed/implemented rather than to be worked around via > other means. Wouldn't you agree? Using username:password@host is *the* standard for encoding this kind of detail. > Besides, passing certain metacharacters in the > proxy host field might not fly well... Every proxy parsing library in existence will support this. (In reply to comment #6) > Would be also nice to see it stored in the gnome keystore. No can do, we need to set this as an environment variable. Using a username and password for a proxy is normally a very bad security model anyway; You can't make it more secure by just hiding the password from plaintext. Designers, do you think a tooltip in the proxy textview such as "Enter a proxy server, e.g. username:password@host" is a good idea? Richard.
Forgive me my ignorance, but... would that model not have issues with usernames/passwords including [:@]? (that's what I really meant regarding metachars)
I set the authentication options in the host field and it was reflected in gconf as expected. However, in my distrib, it shows up under /system/http_proxy, not /system/proxy (my understanding was that the setting was moved to org.gnome.system.proxy). In gnome-control-center the field (HTTP Proxy) now doesn't reflect the settings spite that it's actually set in the backend. I was wondering, could this be distro based? (patches?) Or is this is the originally intended behavior? Thanks, ~ R.
(In reply to comment #7) > Using username:password@host is *the* standard for encoding this kind of > detail. > [snip] > Designers, do you think a tooltip in the proxy textview such as "Enter a proxy > server, e.g. username:password@host" is a good idea? > I'm not a designer, but I really believe this way of entering the password is: a) Horrible at being discoverable (even a tooltip). b) Not user-friendly at all, especially since every other UI that I know of has a separate box for the user/pass. Also, what if any or all of username or password have ':' or '@' in them? It's easier to escape them out if we know which is which rather than having to guess.
Lets flip this around: Using a proxy setup with username/password is horrible and not user-friendly. Talk to whoever forces you to use such a setup.
(In reply to comment #11) > Lets flip this around: Using a proxy setup with username/password is horrible > and not user-friendly. Talk to whoever forces you to use such a setup. This statement demonstrates a horrible, horrible, disconnect from the reality that major users of this feature live in. A huge no. of cases where a proxy setup with user/pass is required, are universities or schools, and the users are students who've heard about this great thing called GNOME 3. These students have absolutely no power to change the network setup which the administration provides (imposes) on them. I'd like to remind you that a major portion of evangelized and recruited manpower for FOSS projects comes from university students. By taking this stand, you're automatically excluding this entire segment. I've been a student at such a university. I can tell you without hesitation, that if GNOME 2 (Ubuntu) had not had the user/pass proxy dialog box, even I would've been simply *unable* to use GNOME, let alone get half my batch to use it and end up contributing to GNOME myself. It took us several years to get proper proxy support throughout GNOME, and with GNOME 3, all that work is going to waste. It's ridiculous.
(In reply to comment #10) > Also, what if any or all of username or password have ':' or '@' in them? It's > easier to escape them out if we know which is which rather than having to > guess. Is this really possible? Any standard requires/prohibits this?
(In reply to comment #13) > (In reply to comment #10) > > Also, what if any or all of username or password have ':' or '@' in them? It's > > easier to escape them out if we know which is which rather than having to > > guess. > > Is this really possible? Any standard requires/prohibits this? I've already had this problem once at my old university, where I had an "@" in my squid http proxy password, because of which I couldn't get the http_proxy env variable to work properly with curl, wget, etc. The usage of ":" and "@" as delimiters usually works fine, but sometimes falls on its face because (afaik) applications and libraries don't restrict the user/pass charset accordingly.
*** Bug 662302 has been marked as a duplicate of this bug. ***
Created attachment 206898 [details] Equivalent interface in Mac OS X http://stackoverflow.com/questions/4204677 Equivalent interface in Windows (I haven't found a non-dialog UI)
Created attachment 206899 [details] Suggested dialog (normal + error cases)
*** Bug 669501 has been marked as a duplicate of this bug. ***
I face the same issue on the network of a company. It uses a BlueCoat HTTP proxy, connected to the corporate ActiveDirectory for user authentication. I unfortunately have no other choice to access the Internet. Second problem : the username/password has to be the one of the ActiveDirectory user, which gives access to all the corporate applications, network shares etc. It would be highly insecure to store it in clear text
*** Bug 677084 has been marked as a duplicate of this bug. ***
still an issue in ubuntu 13.04 :( ! it was not an issue when there was a network proxy option in the older versions of ubuntu that also had a location integration feature of when and where not to use a proxy server on the whole ubuntu system. dconf-editor does have an option for authentication but of course it is in clear TEXT! DEFEATING the whole purpose of an authenticated secure proxy server.. of where a consumer has no choice but to use it at an educational institution.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #10) > > > Also, what if any or all of username or password have ':' or '@' in them? It's > > > easier to escape them out if we know which is which rather than having to > > > guess. > > > > Is this really possible? Any standard requires/prohibits this? > > I've already had this problem once at my old university, where I had an "@" in > my squid http proxy password, because of which I couldn't get the http_proxy > env variable to work properly with curl, wget, etc. > > The usage of ":" and "@" as delimiters usually works fine, but sometimes falls > on its face because (afaik) applications and libraries don't restrict the > user/pass charset accordingly. One solution is to use "%40" instead of "@". All special characters need to be replaced by their HTML encodings when constructing proxy variables.
(In reply to comment #11) > Lets flip this around: Using a proxy setup with username/password is horrible > and not user-friendly. Talk to whoever forces you to use such a setup. How difficult would it be to just add a couple more boxes in the proxy configuration window for username and password. Seriously!! The argument that doing such a thing is a security loophole (as password would be stored in plaintext), is not a valid argument, as now anyways, the only way to achieve proxy authentiation in Gnome is to use Dconf which anyway stores in plain text. Atleast if we have a separate password box, we can make the password hidden as opposed to the totally exposed proxy string in the current setup. Having support for authentication details in Gnome settings is one of the oldest requests I can think of, but for some reason, the Gnome developers don't seem to think this important at all!!
*** Bug 725919 has been marked as a duplicate of this bug. ***
*** Bug 738459 has been marked as a duplicate of this bug. ***
Created attachment 291819 [details] [review] Allow setting the proxy authentication This is an initial attempt at implementing the feature. I implemented it using the master branch and testing it against 3.14. For me it works fine (eventhough accepting the password is stored in plain text). This implementation currently only sets the authentication for HTTP (no HTTPS/FTP/SOCKS), because the field "authentication-user", "authentication-password" and "use-authentication" only exist in the schema "/system/proxy/http". I verified that it works by checking the "http_proxy" variable in my terminal (which also needs the password in plaintext), looking at dconf-editor while doing the changes and running chrome against these settings.
Review of attachment 291819 [details] [review]: you should add link to this bug in patch comment. Other looks good for me.
Review of attachment 291819 [details] [review]: Hi Christoph, thanks for your patch and sorry for the delay. The Network panel underwent a major revamp, and much of the code changed. Because of that, your patch does not apply anymore. Would you please rebase it against master?
Created attachment 369117 [details] [review] Allow setting the proxy authentication - V2 Updated patch to latest git version and review comments.
Georges: Could you please review this patch?
GNOME Settings moved to GitLab. Please open a merge request with this patch. We'll migrate the bugs to GitLab soon.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.