Comments (23)
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 [email protected]
on 6 Oct 2008 at 5:55
from libproxy.
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 [email protected]
on 6 Oct 2008 at 6:00
- Added labels: Type-Enhancement, Priority-High
- Removed labels: Type-Defect, Priority-Medium
from libproxy.
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 [email protected]
on 6 Oct 2008 at 6:11
from libproxy.
Is the keyring a GNOME only thing?
Original comment by [email protected]
on 6 Oct 2008 at 6:26
from libproxy.
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 [email protected]
on 6 Oct 2008 at 6:37
from libproxy.
right, the issue is that accessing the keyring assumes the ability to pop-up
some
kind of login dialog, no?
Original comment by [email protected]
on 6 Oct 2008 at 6:45
from libproxy.
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 [email protected]
on 6 Oct 2008 at 6:52
- Added labels: Milestone-Release0.3
from libproxy.
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 [email protected]
on 6 Oct 2008 at 6:59
from libproxy.
> 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 [email protected]
on 6 Oct 2008 at 7:01
from libproxy.
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 [email protected]
on 6 Oct 2008 at 7:12
from libproxy.
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 [email protected]
on 6 Oct 2008 at 7:14
from libproxy.
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 [email protected]
on 7 Oct 2008 at 1:52
Attachments:
from libproxy.
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 [email protected]
on 7 Oct 2008 at 2:03
- Changed state: Started
from libproxy.
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 [email protected]
on 7 Oct 2008 at 5:07
from libproxy.
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 [email protected]
on 9 Oct 2008 at 7:36
from libproxy.
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 [email protected]
on 9 Oct 2008 at 8:13
from libproxy.
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 [email protected]
on 10 Oct 2008 at 2:08
from libproxy.
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 [email protected]
on 15 Mar 2009 at 3:23
from libproxy.
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 [email protected]
on 15 Mar 2009 at 2:24
from libproxy.
Dan,
This is now supported in 0.3.0. At present we do nothing about storing
passwords.
Original comment by [email protected]
on 14 Aug 2009 at 9:25
from libproxy.
FYI, fetching passwords from gconf is now supported.
Original comment by [email protected]
on 22 Jan 2010 at 8:46
from libproxy.
Original comment by [email protected]
on 22 Jan 2010 at 9:05
- Added labels: Milestone-Release0.4
- Removed labels: Milestone-Release0.3
from libproxy.
Original comment by [email protected]
on 17 Feb 2010 at 2:06
- Added labels: Milestone-Release0.5
- Removed labels: Milestone-Release0.4
from libproxy.
Related Issues (20)
- NetBSD compilation failure HOT 2
- Crash on Mac OS X 10.6 when bypass proxy contains 169.254/16 (works fine on 10.7 and 10.8 though) HOT 1
- Solaris 10 compilation failure HOT 1
- Make get_default_port() threadsafe HOT 2
- libproxy crashes Qt5 applications due to KDE libraries incompatibility HOT 4
- Building a static library of libproxy (i.e. libproxy.a) HOT 1
- url-test test fails on s390 and sparc HOT 7
- crash after pacrunner failure HOT 1
- pacrunner_mozjs is not thread-safe
- Query-string is inadvertedly stripped from PAC GET URL HOT 1
- Use GNUInstallDirs in cmake HOT 1
- Patch for building on OS X 10.9 with libc++
- Findlibproxy.cmake installed in unsuitable directory HOT 1
- MacPorts Patches
- win32-vc90 build crash for "none://localhost:34532" if ProxyOverride in registry is not equal to "<local>" HOT 1
- Assertion failed in char* url::get_pac() HOT 1
- Segmentation Fault on MacOS HOT 1
- Update mozjs to version 24
- needs 95GB of memory?
- SIGSEGV in getProxies() when called from Python thread HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libproxy.