KIO / KWebView and PrivateBrowsing (Cookies)

[Dawit A]

On Mon, Apr 23, 2012 at 1:12 PM, Alex Fiestas <afiestas at kde.org> wrote:

> KWebView can't do Private Browsing because of KIO integration, need advice
> on
> how to fix it but first let me explain the issue.
>
> What I consider PrivateBrowsing:
> Private Browsing should have an empty CookieJar that will keep cookies
> only as
> long as the private browsing is activated, after that cookies will be
> removed.


What is happening now?
> While in PrivateBrowsing all * new * cokies are created with an expiration
> date of "right now" and stored in kcookiejar. This is done by calling
> AccessManager::setDisablecookieStorage(false) and stored in
> CookieJar::setCookiesFromUrl.
>
> File: kdelibs/kio/kio/accessmanager.cpp
>
> All existing cookies will still be available to KWebPage, so even though
> I'm
> in PrivateBrowser authentifications will remain as well as any other
> information stored in the cookies.
>

As a practical usecase, in akonadi-google we need an empty cookieJar so any
> previous authentification on GMail will be ignored  (for example I can be
> authentificated with X account on rekonq while configuring Y account on
> akonadi-google).



> Where is the problem located?
>

The problem is the integration class not doing the right thing right now.
As you already discovered in private browsing mode the cookies are merely
set to session cookies and added to KDE's central cookiejar which violates
the privateness of any cookie.


> As far as I understood the code there are two problems:
>
> -kio_http uses KCookieJar directly, and it doesn't have a Cookie mode like
> the
> one we need. It has: none, manual, auto we will need another one
> (private?).
>

Nope. That is not necessary. The reason the "cookies: manual" meta-data
exists is to allow the client application to deal with cookie management
itself. In this case the client is KIO::Integration::AccessManager.
However, since that class is not doing the right thing, you have this
particular issue.

-kio_http won't use any new QNetworkCookieJar we set via
> AccessManager::setNetworkCookieJar. This is more difficult to fix since
> kio_http is out of process. Maybe we can use some kind of DBus magic?
>

None of this is necessary. What should happen in private browsing mode is
the "cookies" metadata should be set to "manual" to disable cookie handling
kio_http. The KIO::Integration::AccessManager can be modified to send its
own cookie header instead. This would give you want you want. I have
attached an untested patch that does just that. Test it and let me know if
it works okay for you.

The only question I have and which the patch does not address is whether or
not cookies stored outside of the private-browsing mode should be used
(read: sent back to the server) during private browsing mode. Reading the
up on the definition of private browsing mode, it seems to me that we
should only stop saving information once in private browsing mode, not stop
sending data that was previously stored before "private browsing mode" was
initiated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120423/ecfd88a6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kio_accessmanager_private_browsing_mode.patch
Type: application/octet-stream
Size: 5881 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120423/ecfd88a6/attachment.obj>