KIO / KWebView and PrivateBrowsing (Cookies)
afiestas at kde.org
Wed Apr 25 18:05:08 BST 2012
On Wednesday, April 25, 2012 10:23:27 AM Dawit A wrote:
> On Tue, Apr 24, 2012 at 8:13 AM, Alex Fiestas <afiestas at kde.org> wrote:
> > After reading the patch and understanding a little bit more how this work
> > I
> > reached the following conclusion (potentially wrong as before :p).
> > storageDisabled should work as it does right now (without the patch), it
> > does
> > disable any storage and allow reading, which imho it is exactly what you
> > expect from "disable storage".
> > So, how do we enable Private Browsing in AcessManager?
> > By setting a different CookieJar, the default Qt implementation will do
> > the
> > job perfectly storing all the cookies in memory until the jar is destroyed
> > (Private Browsing disabled).
> > Right now any new CookieJar set via QNetworkAccessManager::setCookieJar
> > will
> > be ignored by Integration::AccessManager since at the end kio_http will
> > use
> > the "auto" cookie mode.
> > So, the solution should be:
> > -Fix the support for external QNetworkCookieJar's, this will have to be
> > done
> > anyway since Integration should have support for it.
> > -Fix KWebPage to set a custom CookieJar when private browsing is
> > activated.
> > What do you think? does it make any sense at all this time?
> Well actually it is a little bit simpler than that to get to what you want.
> Keeping only the portion of my patch that deals with disabling cookie
> handling in kio_http along with you setting your own custom cookiejar
> through QWebPage::networkAccessManager()->setCookieJar should be sufficient
> for what you are trying to do.
I will try to provide a patch, thanks for the support !
> However, to properly fix the issue of "private browsing mode" for more
> complex scenarios like allowing two separate instances of web browsers to
> share cookies as it is done in other browser implementations (I checked
> Chromium) requires a little bit more involved fix. We would need to use the
> cookiejar and that means we need a way to mark such cookies as private to
> the cookiejar. The trick is to do that without having to modify any of the
> KDE cookiejar code. I will see what I can do about that...
I have been willing to do a small app to load a single KDED for months
now,though I wanted to do it for ease the development of a KDED that very same
app could be used to execute another instance of KCookieJar.
Flow should be something like:
1-User actiavte's private browsing
2-rekonq executes a custom KCookieJar
-This could be done automatically within kdewebkit but we are in freeze
-Once we fix the "Be able to use custom CookieJars with KWebkit" rekonq
could write one to use this custom KCookieJar instance
3-Once private browsing is deactiavted, the small app is closed deleting all
Something I really like from that approach is that we keep things "phisically"
separated, kded4 will handle real cookies while the new instance will handle
At the same time, if wanted we should be able to have multiple private
More information about the kde-core-devel