Use LibSecret to store logins [$400]

[Cris Dywan]

It would be nice if Midori could use the GNOME or KDE keyring service to store logins, rather than its own file, if available. This applies to HTTP authentification as well as login forms, see also bug 786534.

[Cris Dywan (kalikiana)]

This is libsecret now: http://people.gnome.org/~stefw/libsecret-docs/complete.html

[Danielle Foré (danrabbit)]

Bounty on BountySource: https://www.bountysource.com/issues/358193-use-libsecret-to-store-logins

[Robert Roth (evfool)]

For anyone wanting to work on a patch, I have updated the extension attached to compile with the latest midori trunk, tested that storing in the keyring works.
* Retrieving didn't work for me, probably a syntax error in the JavaScript file, needs to be fixed
* the gnome-keyring calls replaced with libsecret calls
* make sure that CMake/make installs the js file in DATADIR/midori/res/

[Sam Hegarty (hegarty-sam)]

It looks like the current formhistory extension has this has keyring support as a TODO (http://bazaar.launchpad.net/~midori/midori/trunk/view/head:/extensions/formhistory/formhistory.c#L152). Would adding it here be the way to go? If so then what should I do about HTTP requests? Another extension or add it to formhistory?

[Paweł Forysiuk (tuxator)]

I think the preffered way is to work on this branch

https://code.launchpad.net/~midori/midori/formHistory3

There was a plan to rewrite form history in vala with current extension as a base (similar to what we did with adblock extension). The plan was to have some kind of (exchangeable) abstraction for storing password which you could optionally disable. For example there is no libsecret on windows or for older versions of webkitgtk that we still support. While it should not hold everything else back if you have a good abstraction is should not be much work to add some _backends_ for password storage like gnome-keyring or win crypto api for example.