proxy authentication

[GoogleCodeExporter]

Some proxies require authentication. libproxy does not currently handle this.

The easiest change would be to just declare that the proxy URIs returned
from px_proxy_factory_get_proxies() might include a username and password
(ie, http://user:pass@host:port). Indeed, it seems that some apps already
handle that syntax in the http_proxy environment variable, and KDE also
allows its use in the kioslaverc httpProxy key.

However, libproxy won't currently allow a backend to give it URIs
containing username and password, because pxURL won't accept them.

I can update pxURL to deal with this if you want. It's a biggish change
though, since pxURL would have to be able to deal with %-encoded URL
elements now, since the password might have a "@" or "/" in it.

I already have a patch to make the GNOME backend return auth info in this
format, but it doesn't work because of the pxURL problems.

Original issue reported on code.google.com by dan.wins...@gmail.com on 6 Oct 2008 at 5:47

Attachments:

• gnome-proxy-auth.diff

[GoogleCodeExporter]

Hm... just noticed that this is listed as not-a-bug in the FAQ.

I don't think there's any advantage to *not* returning the username and 
password to
the caller, if the underlying backend knows it.

At any rate, currently if you configure HTTP proxy authentication in KDE or via
$http_proxy, then libproxy doesn't work at all, so that at least should be 
fixed.

Original comment by dan.wins...@gmail.com on 6 Oct 2008 at 5:55

[GoogleCodeExporter]

You're right this is something we should support.  However, I do want to note 
that
the scope of libproxy is configuration and configuration analysis.  We don't do 
the
actual proxy negotiation.  However, it is totally within our scope to report 
what the
configuration has with proxies.

Now, on the GNOME side of things I assume proxy authentication should go into 
the
keyring, no?  Currently, it is stored unencrypted in GConf which is not the most
elegant solution.  I would consider supporting GConf as a backwards 
compatibility
measure though...

What are your thoughts?

Original comment by npmccallum@gmail.com on 6 Oct 2008 at 6:00

• Added labels: Priority-High, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Yeah, I was pondering whether or not GNOME should change this on its end. The 
problem
with that is, if you're running a mix of GNOME+libproxy and KDE+libproxy apps 
under
GNOME, then they'd all see the same proxy configuration, but only the GNOME ones
would be able to see the password.

Original comment by dan.wins...@gmail.com on 6 Oct 2008 at 6:11

[GoogleCodeExporter]

Is the keyring a GNOME only thing?

Original comment by npmccallum@gmail.com on 6 Oct 2008 at 6:26

[GoogleCodeExporter]

yeah. GNOME has gnome-keyring, KDE has kwallet, etc. There's no shared standard.

(Of course, if GNOME moved the proxy password into gnome-keyring, then the 
libproxy
GNOME plugin could just read it out of there instead of reading it out of 
GConf, thus
rescuing the KDE+libproxy apps. And likewise with the KDE plugin if KDE moved 
their
proxy password into kwallet.)

Original comment by dan.wins...@gmail.com on 6 Oct 2008 at 6:37

[GoogleCodeExporter]

right, the issue is that accessing the keyring assumes the ability to pop-up 
some
kind of login dialog, no?

Original comment by npmccallum@gmail.com on 6 Oct 2008 at 6:45

[GoogleCodeExporter]

So I think there are several steps here:
1. Make libproxy support credentials coming from the backends
2. Add support for credentials using existing methods (ie. gconf, etc)
3. Devise better methods of storing credentials (keyring, kwallet, etc)

I'd like to do #1 and #2 for the 0.3 release.  Anything further you'd like to 
add?

Original comment by npmccallum@gmail.com on 6 Oct 2008 at 6:52

• Added labels: Milestone-Release0.3

[GoogleCodeExporter]

ah, no, libgnomekeyring does not get involved with UI itself. It's basically 
just a
database for passwords, and it leaves the actual interaction with the user to 
the
application.

So the theoretical plugins/gnome.c integration with gnome-keyring would just 
involve
having it making a call to gnome_keyring_find_network_password_sync(), and if 
it got
back a result, it would include it in the URI, and if not, it would return the 
URI
with no username and password. So if gnome-keyring [or gconf] already knows the
password, then it makes life easier for the application, and if gnome-keyring 
[or
gconf] doesn't already know the password, then the application is in exactly 
the same
situation it would be with the current code, where it's left to its own devices 
if it
wants to get a password.

Original comment by dan.wins...@gmail.com on 6 Oct 2008 at 6:59

[GoogleCodeExporter]

> Anything further you'd like to add?

Nope, 1 and 2 was all I wanted for now.

Are you planning to hack on this or should I write up a patch with the pxURL 
changes
myself?

Original comment by dan.wins...@gmail.com on 6 Oct 2008 at 7:01

[GoogleCodeExporter]

I'll hack on this.  Its my goal to solve both this bug and #7 in the next week 
or so
and release 0.3.

Original comment by npmccallum@gmail.com on 6 Oct 2008 at 7:12

[GoogleCodeExporter]

well, actually, now that I think about this, you might be more familiar with the
needs of pxURL (especially %-encoding).  So if you want to do that, I won't 
complain.

Original comment by npmccallum@gmail.com on 6 Oct 2008 at 7:14

[GoogleCodeExporter]

So actually, it turns out pxURL doesn't really need to care about
escaping/unescaping, since it never looks at the username and password itself. 
So it
just needs to be updated to split everything up in the right places; in 
particular,
if there's an '@' after the "://" but before the end of the host:port string, 
then it
has to split the userinfo (username:password) from the host:port at that point.

This patch does that, but I ended up rewriting px_url_new pretty extensively, 
to be
keeping track of the start and end of various pieces of the URL. And I got rid 
of the
sanity-check-by-reassembling at the end, because there were just too many cases 
now
and it would have been a pain. But maybe you want to put that back... Anyway, I 
won't
be upset if you rewrite this patch in some way that makes more sense to you.

Original comment by dan.wins...@gmail.com on 7 Oct 2008 at 1:52

Attachments:

• proxy-auth.diff

[GoogleCodeExporter]

We also need to think about the following case:
1. John uses multiple proxies, each with its own username/password
2. John uses WPAD to automatically switch between them

There is really a three step process that goes on here.
1. Determine which configuration to use (WPAD, PAC, Manual, None)
2. Determine which proxy to use (ie. type, hostname, port)
3. Determine which credentials to use

You then have configuration like this stored somewhere:
"http://proxy.foo.com:8080" => ("john", "j0hn$pa$$w0rd")

Thoughts?

Original comment by npmccallum@gmail.com on 7 Oct 2008 at 2:03

• Changed state: Started

[GoogleCodeExporter]

I don't really know much about the specifics of real-world proxy 
configurations. I've
only once ever been on a network where I needed to configure a proxy in order to
access the outside world. But yeah, clearly, in most PAC/WPAD configurations, 
the PAC
script is not going to be returning usernames+passwords as part of the proxy 
URLs.

But I don't think it makes sense for libproxy to become a password store. There 
are
security issues, etc, involved with that. If you want libproxy to get more 
involved
with credentials, it should just use backend-specific mechanisms. 
(gnome-keyring for
the gnome backend, kwallet for kde, etc).

Original comment by dan.wins...@gmail.com on 7 Oct 2008 at 5:07

[GoogleCodeExporter]

I wasn't suggesting to make libproxy a password store.  By "stored somewhere" I 
mean,
"this is the kind of lookup the backends should implement."

So following the use case above, the implementation would look something like:
1. Get configuration from GConf
2. GConf gave us WPAD, so run the WPAD stuff.  This gives us a list of proxies 
to try
to use.
3. For each proxy returned by WPAD, try to get the credentials for *that* proxy 
from
GNOME Keyring.
4. Return the proxies to use and their credentials (in some format)

Now, the question I have is this: are there credentials that we need to worry 
about
that are not username/password (i.e. kerberos)?

Original comment by npmccallum@gmail.com on 9 Oct 2008 at 7:36

[GoogleCodeExporter]

Don't worry about anything except passwords. Kerberos is a non-problem, because 
all
kerberos-aware apps have access to the user's kerberos tickets, so if the proxy
requires kerberos auth, and the app knows how to do kerberos auth, then they're 
all
set, and if the app doesn't know how to do kerberos auth, then there's nothing
libproxy can do about it unless it plans to negotiate the proxy connection 
itself.
And for things like authenticating via client ssl certificates, if you're going 
to
try to extend libproxy's API to cover that, then you're going to end up 
implementing
a complete cross-desktop keyring API which is going to take forever.

So just passwords.

> 3. For each proxy returned by WPAD, try to get the credentials for *that* 
proxy
from GNOME Keyring.

There might be an argument for not requesting the passwords until after the
application has determined that it needs it. Some keyring systems pop up 
"Application
'foo' has requested access to the password for 'bar'. Is this OK?" dialogs in 
some
circumstances, and you don't want to cause more than one of them if the first
password is going to be enough.

Also, you presumably want an API for the app to say "that password didn't work" 
and
also, to ask libproxy to *store* a password (otherwise the password will never 
get
stored into the backend in the first place). So:

bool px_proxy_factory_get_credentials(pxProxyFactory *, const char *uri,
                                      char **user, char **password);
void px_proxy_factory_set_credentials(pxProxyFactory *, const char *uri,
                                      const char *user, const char *password);

(where the user and password can be NULL to clear it)

This still feels bizarreish to me though. Most network-using applications are 
going
to be making use of passwords for things other than proxies as well, and so 
they're
going to be using the desktop native keyring API, or else some home-brewed API. 
But
then for proxy credentials, they're suddenly expected to use something 
different.
It's weird.

Original comment by dan.wins...@gmail.com on 9 Oct 2008 at 8:13

[GoogleCodeExporter]

I agree that this feels bizarreish...  Particularly because its far easier to 
know
which database to read from (the first one that has a key matching this proxy) 
than
it is to know which one to write to (you might not write to the database you are
reading from).  This is why in particular I have avoided this feature thus-far.

You also have the added complexity that, once a database write has been 
performed,
should this database have priority?

I don't yet see a clear path forward...

Original comment by npmccallum@gmail.com on 10 Oct 2008 at 2:08

[GoogleCodeExporter]

OK, now that the PluginManager has landed there is rudimentary support for
credentials internally.  We have the following left to do:
1. Figure out the best way to expose this to the user.
2. Make the backends actually support credentials

Original comment by npmccallum@gmail.com on 15 Mar 2009 at 3:23

[GoogleCodeExporter]

I still think the best plan is for libproxy to merely allow the plugins to pass
username and password in the URL *if the plugin already knows it*, and not worry
about trying to remember/find passwords. That is Somebody Else's Problem.

Original comment by dan.wins...@gmail.com on 15 Mar 2009 at 2:24

[GoogleCodeExporter]

Dan,

This is now supported in 0.3.0.  At present we do nothing about storing 
passwords.

Original comment by npmccallum@gmail.com on 14 Aug 2009 at 9:25

[GoogleCodeExporter]

FYI, fetching passwords from gconf is now supported.

Original comment by npmccallum@gmail.com on 22 Jan 2010 at 8:46

[GoogleCodeExporter]

Original comment by npmccallum@gmail.com on 22 Jan 2010 at 9:05

• Added labels: Milestone-Release0.4
• Removed labels: Milestone-Release0.3

[GoogleCodeExporter]

Original comment by npmccallum@gmail.com on 17 Feb 2010 at 2:06

• Added labels: Milestone-Release0.5
• Removed labels: Milestone-Release0.4