GNOME Bugzilla – Bug 594377
Figure out SoupPasswordManager
Last modified: 2012-12-11 15:23:00 UTC
There was some confusion between Xan and me around SoupPasswordManager and HTTP auth. The net result of this is that it may not make sense to have WebKit/epiphany pass forms-based auth through SoupPasswordManager, in which case it probably does not make sense for SoupPasswordManager to exist at all, since browsers would need to use gnome-keyring (eg) directly for forms-based auth, and so it would be simpler for them to just use it directly for HTTP auth as well. We are still not totally sure about this, and given the way that the feature is currently split between libsoup, webkit, and epiphany, it would be hard to fix it quickly without going back to the previous broken state where webkit had to be built linked against gnome-keyring, which most distros weren't doing, which meant epiphany couldn't save passwords. So, the plan for 2.28.0 is that the SoupPasswordManager APIs will be hidden behind a #define, and removed from the docs (er... "not belatedly added to the docs", oops :-), and we don't know what will happen in 2.30 (or even 2.28.1). WebKit/epiphany and other code that wants to use it in 2.28 should #define the #define, AND also wrap the relevant code in #ifdef SOUP_TYPE_PASSWORD_MANAGER, so that if/when it goes away, people will still be able to compile older WebKit, etc, tarballs against the new libsoup, just with a loss of password-saving functionality.
Created attachment 142625 [details] [review] Remove SoupPasswordManager from the stable API See
The magic words are: #define LIBSOUP_I_HAVE_READ_BUG_594377_AND_KNOW_SOUP_PASSWORD_MANAGER_MIGHT_GO_AWAY
original discussion at bug 522776. In more detail, the problem is with the differences between HTTP auth and forms-and-cookies auth, and with the features browsers want to implement. HTTP auth: - libsoup handles the mechanics; the app just needs to provide passwords - no concept of login/logout, so libsoup has to send the password with every request, meaning it *must* cache the password in memory for as long as you might want to use the site. Forms-and-Cookies auth: - browser handles the mechanics; libsoup doesn't even know it's happening - password only needed at login, so browser only needs to remember it if it wants to use the site again after you have logged out, so there's a distinction between "remember for this session" and "remember forever" So, if we were going to add support to SoupPasswordManager for forms-and-cookies, then SoupPasswordManager would basically just be acting as a dumb database, and that might be... well, dumb. You either have: - Old way: - HTTP auth: libsoup emits a signal, epiphany/WebKit looks up passwords in gnome-keyring, lets user decide whether or not to use it, gives password to libsoup - Forms auth: epiphany/WebKit decides a password is needed, looks it up in gnome-keyring, lets user decide whether or not to use it, fills in form (no libsoup involvement) - SoupPasswordManager way: - HTTP auth: libsoup looks up passwords in gnome-keyring, emits a signal, epiphany/WebKit lets user decide whether or not to use it, gives password to libsoup - Forms auth: epiphany/WebKit decides a password is needed, looks it up in SoupPasswordManager, lets user decide whether or not to use it, fills in form (no libsoup involvement) One problem with the old way was that it required WebKit to be linked against gnome-keyring, which some distros weren't doing because they didn't want the extra dependency, and so epiphany ended up without password-saving support. This could be fixed by having WebKit emit signals or whatever so that the application could handle the actual password looking-up/saving. But then you're basically just reimplementing the proposed forms-auth-in-SoupPasswordManager API in WebKit... Christian suggests that having the gnome-keyring bits be in libsoup-gnome is nice because then midori and other browsers can use it too, whereas if had to be done per-browser, epiphany and midori would have duplicated code. Xan points out that this is really only a few lines of code though. The hard parts are in the dialogs (password dialog, and password manager), and WebKitGTK provides the first, and no one except the browser provides the second under any proposal.
Created attachment 176237 [details] [review] patch to WebKit for SoupPasswordManager removal
Created attachment 176238 [details] [review] patch to epiphany for SoupPasswordManager removal (incomplete!)
So, here's the start of webkit and epiphany patches to deal with SoupPasswordManager going away. Basically, we add some new signals to WebKitSoupAuthDialog, and then connect to those signals from epiphany, and epiphany provides the keyring lookup/saving functionality for WebKit. The WebKit patch should be more-or-less complete, but it's not tested (ie, compiled) yet. The epiphany patch is only halfway there; the part left is to make it cache http passwords in addition to form passwords, so it can respond to the webkit signals correctly. The relevant gnome-keyring attributes are: user: user server: msg->uri->host port: msg->uri->port protocol: msg->uri->scheme domain: soup_auth_get_realm(auth) authtype: soup_auth_get_scheme_name(auth) it would need to cache all usernames/passwords where protocol was "http" or "https", and then match up the other attributes to the requests from webkit later on.
So... how does WebKit2 affect this? Are we ready for SoupPasswordManager to go away?
It's kinda moot, isn't it? The interface to gnome-keyring that you're trying to use was removed in gnome-2-30, more than 2 years ago. At the very least you should switch configure.ac to make building without it the default.
No, the API is still there, it's just that the library was split off into a separate package (libgnome-keyring instead of gnome-keyring)
Aha! Thanks, and sorry for the noise.
(In reply to comment #7) > So... how does WebKit2 affect this? Are we ready for SoupPasswordManager to go > away? In WebKit2 we are currently showing the dialog from the WebProcess (without password saving support) which is not a good idea. We plan to move the dialog to the UI process, and figure out how to add support for password saving.
See also bug 679866 and bug 679918. I plan to remove gnome-keyring support from libsoup for GNOME 3.8 (making SoupPasswordManagerGNOME a no-op). And SoupPasswordManager in general will become a legacy API that won't work with some new features, and then eventually go away entirely.
My plan right now (it's still evolving) is to remove SoupPasswordManager support from WebKit entirely and go with the signal approach. The WebView will emit an "authenticate" signal. The listener attached to the signal will allow passing a username, password, and an argument specifying whether the password should be remembered for the session, forever, or not at all. Default password storage will be via libsecret (depending on whether it was present when you compiled WebKit). Here's the bug tracking removing SoupPasswordManager interaction from WebKit: https://bugs.webkit.org/show_bug.cgi?id=99914
Maybe we could use a simpler approach, where the auth signal doesn't say anything about storing passwords, leaving that part to the applications, so that applications can use libsecret or any other thing, and we avoid the dependency in WebKit (even if it's a soft dependency). If the signal is not handled by the application the default handler could show the dialog we currently have and use libsecret optionally if available.
The ResourceHandle needs to interact directly with the credential storage for a full integration. For instance, if the password is later rejected, it will want to remove the password from the credential store (among other things). To avoid a libsecret dependency (though I'm not sure a soft dependency would be so bad), we can add another set of signals for adding and removing credentials from permanent storage.
Yes, I haven't said a soft dependency on libsecret is so bad, I even proposed to use it optionally for the default implementation when the user doesn't handle the signal. I just think it would be great if the apps can implement their own secrets storage, as we do with other parts of the API. But I'm just wondering without even knowing how the whole thing work, so if it's not possible or too complex, I'm fine with using it internally and only provide a way to implement to dialog.
SoupPasswordManager is now gone. (Well, it's still there for ABI compat, but it no longer does anything.)