<div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 23, 2012 at 1:12 PM, Alex Fiestas <span dir="ltr"><<a href="mailto:afiestas@kde.org" target="_blank">afiestas@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


KWebView can't do Private Browsing because of KIO integration, need advice on<br>
how to fix it but first let me explain the issue.<br>
<br>
What I consider PrivateBrowsing:<br>
Private Browsing should have an empty CookieJar that will keep cookies only as<br>
long as the private browsing is activated, after that cookies will be removed.</blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What is happening now?<br>



While in PrivateBrowsing all * new * cokies are created with an expiration<br>
date of "right now" and stored in kcookiejar. This is done by calling<br>
AccessManager::setDisablecookieStorage(false) and stored in<br>
CookieJar::setCookiesFromUrl.<br>
<br>
File: kdelibs/kio/kio/accessmanager.cpp<br>
<br>
All existing cookies will still be available to KWebPage, so even though I'm<br>
in PrivateBrowser authentifications will remain as well as any other<br>
information stored in the cookies.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As a practical usecase, in akonadi-google we need an empty cookieJar so any<br>
previous authentification on GMail will be ignored  (for example I can be<br>
authentificated with X account on rekonq while configuring Y account on<br>
akonadi-google).</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Where is the problem located?<br></blockquote><div><br></div><div>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.</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As far as I understood the code there are two problems:<br>
<br>
-kio_http uses KCookieJar directly, and it doesn't have a Cookie mode like the<br>
one we need. It has: none, manual, auto we will need another one (private?).<br></blockquote><div><br></div><div>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.</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-kio_http won't use any new QNetworkCookieJar we set via<br>
AccessManager::setNetworkCookieJar. This is more difficult to fix since<br>
kio_http is out of process. Maybe we can use some kind of DBus magic?<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div>
<div><br></div><div><br></div></div></div>