After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 646354 - Network proxy has no proxy authorization
Network proxy has no proxy authorization
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: Network
3.28.x
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
triaged
: 662302 669501 677084 725919 738459 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-03-31 15:46 UTC by yahyai-0
Modified: 2021-06-09 16:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
picture for network proxy setting (50.13 KB, image/png)
2011-03-31 15:46 UTC, yahyai-0
  Details
Equivalent interface in Mac OS X (60.78 KB, image/png)
2012-02-06 15:04 UTC, Matthew Paul Thomas (mpt)
  Details
Suggested dialog (normal + error cases) (25.28 KB, image/png)
2012-02-06 15:08 UTC, Matthew Paul Thomas (mpt)
  Details
Allow setting the proxy authentication (10.45 KB, patch)
2014-11-30 11:05 UTC, Christoph Brill
none Details | Review
Allow setting the proxy authentication - V2 (9.81 KB, patch)
2018-02-28 21:15 UTC, Jan-Michael Brummer
none Details | Review

Description yahyai-0 2011-03-31 15:46:41 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
Comment 1 Richard Hughes 2011-03-31 21:00:27 UTC
Can't you just use the standard proxy format, e.g. username:password@server:port
Comment 2 yahyai-0 2011-04-01 04:24:06 UTC
For me it is ok 
But for others especially noobs
Comment 3 darknesscore 2011-04-05 14:08:31 UTC
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
Comment 4 Richard Hughes 2011-04-06 09:31:49 UTC
(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.
Comment 5 dc 2011-09-08 14:05:07 UTC
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).
Comment 6 dc 2011-09-08 16:44:10 UTC
Would be also nice to see it stored in the gnome keystore.
Comment 7 Richard Hughes 2011-09-08 16:56:52 UTC
(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.
Comment 8 dc 2011-09-08 17:15:04 UTC
Forgive me my ignorance, but... would that model not have issues with usernames/passwords including [:@]? (that's what I really meant regarding metachars)
Comment 9 dc 2011-09-08 18:50:32 UTC
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.
Comment 10 Nirbheek Chauhan 2011-09-29 06:25:58 UTC
(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.
Comment 11 Matthias Clasen 2011-09-30 12:38:34 UTC
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.
Comment 12 Nirbheek Chauhan 2011-09-30 13:31:59 UTC
(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.
Comment 13 Peter 2011-10-01 08:24:13 UTC
(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?
Comment 14 Nirbheek Chauhan 2011-10-01 13:32:49 UTC
(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.
Comment 15 Bastien Nocera 2011-10-20 16:01:32 UTC
*** Bug 662302 has been marked as a duplicate of this bug. ***
Comment 16 Matthew Paul Thomas (mpt) 2012-02-06 15:04:36 UTC
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)
Comment 17 Matthew Paul Thomas (mpt) 2012-02-06 15:08:37 UTC
Created attachment 206899 [details]
Suggested dialog (normal + error cases)
Comment 18 Bastien Nocera 2012-02-07 10:56:44 UTC
*** Bug 669501 has been marked as a duplicate of this bug. ***
Comment 19 mossroy 2012-03-04 14:39:36 UTC
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
Comment 20 Matthias Clasen 2012-05-30 17:00:54 UTC
*** Bug 677084 has been marked as a duplicate of this bug. ***
Comment 21 ljelly 2013-03-13 07:25:52 UTC
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.
Comment 22 Karthik 2014-07-29 11:52:43 UTC
(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.
Comment 23 Karthik 2014-07-29 11:59:08 UTC
(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!!
Comment 24 Bastien Nocera 2014-10-13 14:30:13 UTC
*** Bug 725919 has been marked as a duplicate of this bug. ***
Comment 25 Bastien Nocera 2014-10-13 14:30:41 UTC
*** Bug 738459 has been marked as a duplicate of this bug. ***
Comment 26 Christoph Brill 2014-11-30 11:05:39 UTC
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.
Comment 27 Igor Gnatenko 2014-11-30 12:36:39 UTC
Review of attachment 291819 [details] [review]:

you should add link to this bug in patch comment. Other looks good for me.
Comment 28 Igor Gnatenko 2014-11-30 12:36:41 UTC
Review of attachment 291819 [details] [review]:

you should add link to this bug in patch comment. Other looks good for me.
Comment 29 Georges Basile Stavracas Neto 2018-01-26 02:14:53 UTC
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?
Comment 30 Jan-Michael Brummer 2018-02-28 21:15:09 UTC
Created attachment 369117 [details] [review]
Allow setting the proxy authentication - V2

Updated patch to latest git version and review comments.
Comment 31 Jan-Michael Brummer 2018-05-16 19:22:25 UTC
Georges: Could you please review this patch?
Comment 32 Georges Basile Stavracas Neto 2018-07-17 02:40:50 UTC
GNOME Settings moved to GitLab. Please open a merge request with this patch. We'll migrate the bugs to GitLab soon.
Comment 33 André Klapper 2021-06-09 16:28:45 UTC
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.