(In reply to comment #0)
> Using GNOME_KEYRING_NETWORK_PASSWORD schema, domain would be set to the "auth
> identifier" (the "scheme:realm" string), with everything else pretty obvious.
> (Need to make sure that other http-using apps do this the same way though.)

This was based on the discussion the network password scheme on live.gnome.org, but it turns out that the relevant methods actually let you specify both "domain" (realm) and "authtype" (scheme), so we don't need any special handling.


initial work can be seen on the keyring branch of http://gnome.org/~danw/libsoup.git

Any news on this (or on how Epiphany/Webkit could use it)?

the bits in the git repo mostly work; I think this can definitely happen for 2.26.

Can you please add this to http://live.gnome.org/RoadMap ?

Dan, ping?

Right, ok, so this is still in exactly the same state it was in in when I last commented in October, which makes it basically too late to go in now.

For epiphany in particular though, it's not totally clear that gnome-keyring support *in libsoup* is interesting, since ephy will need to also handle keyring support for passwords in HTML forms (which libsoup would be completely unaware of), so if it uses libsoup's keyring support for HTTP auth passwords, then it would end up with two completely separate password-remembering codepaths... 

Also, gvfs wouldn't use it either, because gvfs backends have to use gvfs's password code, so that when they need to ask for a password, it gets proxied from the backend over to nautilus, etc.

So I'm not totally sure this makes sense now. What do the other people cc:ed here think? Are there other projects where having gnome-keyring support in libsoup (rather than at a higher level in the application) would make a lot of sense?

(In reply to comment #6)
> Are there other projects where having gnome-keyring support in
> libsoup (rather than at a higher level in the application) would make a lot of
> sense?

Even if so, will anybody see this question and answer here? ;-)
Maybe ask on d-d-l...

(In reply to comment #6)
> Right, ok, so this is still in exactly the same state it was in in when I last
> commented in October, which makes it basically too late to go in now.
> 
> For epiphany in particular though, it's not totally clear that gnome-keyring
> support *in libsoup* is interesting, since ephy will need to also handle
> keyring support for passwords in HTML forms (which libsoup would be completely
> unaware of), so if it uses libsoup's keyring support for HTTP auth passwords,
> then it would end up with two completely separate password-remembering
> codepaths... 
> 

I understand this, but how are we supposed to get the auth data to use in HTTP auth from keyring without keyring support in libsoup? The codepaths might be different, but we still want to store all the auth data in keyring in general. (I'm just asking, far from being an expert on this).

(In reply to comment #8)
> I understand this, but how are we supposed to get the auth data to use in HTTP
> auth from keyring without keyring support in libsoup? The codepaths might be
> different, but we still want to store all the auth data in keyring in general.
> (I'm just asking, far from being an expert on this).

You'd just connect to SoupSession::authenticate like normal, but instead of popping up a dialog and asynchronously asking for a password right away, you'd make an asynchronous call to gnome-keyring first instead. Eg:

	gnome_keyring_find_network_password (
		NULL,                             /* user -- accept any */
		soup_auth_get_realm (auth),       /* domain */
		uri->host,                        /* server */
		NULL,                             /* object -- unused */
		uri->scheme,                      /* protocol */
		soup_auth_get_scheme_name (auth), /* authtype */
		uri->port,                        /* port */
		find_password_callback, auth_data, free_auth_data);

(that's copied from soup-password-manager-gnome.c). Then you get back a list of saved usernames and passwords, and create your password dialog using that.

All the keyring-integration code does is it makes that call for you, so that the information about saved users and passwords will already be available on the SoupAuth object by the time the "authenticate" signal is emitted.

OK, that makes sense. It would go directly into WebKit with a --enable-gnome-keyring mode or something. Good thing the soup backend won't be optional anymore, otherwise the configure checking would be a mess :)

(In reply to comment #6)
> So I'm not totally sure this makes sense now. What do the other people cc:ed
> here think? Are there other projects where having gnome-keyring support in
> libsoup (rather than at a higher level in the application) would make a lot of
> sense?

If I understang things correctly (I'm not sure I do), this would make sense for Liferea (I'm porting it from curl/glibcurl to libsoup). Right now passwords are stored as plain text in the feed list, so since now libsoup is going to do the update work it would make sense for it to have keyring support in our case.

this happened, in 2.27.91