rekonq 2 merged in rekonq main repository

[Dawit A]

Well if we simply ignore the "private session" cookies in the cookie
management dialog, then the problem becomes much easier. One will only have
to add the concept of "private" cookies to the cookiejar and make sure
cookies marked as such are always treated as session cookies and only
available to windows that claim to be "private". That is not a difficult
thing to accomplish. I have to see how the other browsers handle that
situation.

BTW, there is a very big limitation to using QNAM and QNetworkCookieJar to
implement "private" browsing mode. Your "private" session is limited to one
single window. If you launch a second window in "private" mode, then it
will not be able to share the private cookies with the other private
window. Dunno if that is a desired behavior for you but I think chrome
allows that by default. I dunno what Firefox does, but I am sure its
behavior is probably similar.

Anyhow, I am will try to find some time to add "private" browsing mode
support for kcookiejar during the upcoming holidays. Otherwise, I will
outline how to do it and someone else can take a crack at it.


On Wed, Dec 19, 2012 at 1:05 PM, andrea diamantini <adjam7 at gmail.com> wrote:

> I though that way, too. My problem was just that implementing my ideas
> about did not lead to a "working" solution. And I really cannot release
> another time with a private "non-really-private" incognito mode.
> About your difficulties, I can just say that, IMHO, "private session"
> cookies have to be completely ignored even from the cookie dialog. They
> cannot be stored on disk. And they have to disappear from memory as soon as
> the private session ends.
> That's because the "empty cookiejar problem" looks similar. And using Qt
> network classes seems easier.
> On QNAM you can create a QNetworkCookieJar on the fly, use and delete it
> when your session finishes. With KIO you cannot do this as we have just ONE
> cookiejar kde-wise. So the approach has to be:
> - you cannot no more store cookies (dawit just implemented this, I think)
> - you cannot no more use old cookies stored (my first attempt here failed)
> - you have to manage your session "session cookies" (that is, use in your
> private session and delete them when it (and NOT kde session) finishes).
>
>
>
> 2012/12/19 Dawit A <adawit at kde.org>
>
>> Well that is not entirely correct. We can definitely implement support
>> for private mode in the cookiejar itself easily. There are a couple of
>> approaches we can take. The difficult part has always been how to handle
>> the "private session" cookies in the cookie management dialogs. Anyhow, I
>> promised to try and implement this for 4.10, but I could not find the time.
>> Perhaps I will find some time during the upcoming holidays.
>>
>>
>> On Mon, Dec 17, 2012 at 7:18 PM, andrea diamantini <adjam7 at gmail.com>wrote:
>>
>>> Yes, I'm obviously trying.
>>> My first attempt was a tiny change in the KCookieServer/KCookieJar API
>>> to let people search just for persistent cookies.
>>> But it failed.
>>> I'm currently working on a second attempt following the same approach.
>>> If not, I though about implementing a different jar for the private
>>> sessions. But this second idea is probably an "hard" change in the kde
>>> cookie jar.
>>> I fear that "private sessions" are exactly the opposite idea around what
>>> the "monolithic" & "share it with every app" kde cookie jar is builded.
>>>
>>>
>>> 2012/12/17 David Faure <faure at kde.org>
>>>
>>>> On Sunday 16 December 2012 18:41:31 andrea diamantini wrote:
>>>> > - New private browsing mode (NOT based on KIO, as it seems our
>>>> cookiejar is
>>>> > not enough "malleable" for it. At least in kde4)
>>>>
>>>> Are you working on patches to make it "malleable" enough in the future?
>>>>
>>>> If you need something, make it happen, don't just hope for others to do
>>>> so :)
>>>>
>>>> --
>>>> David Faure, faure at kde.org, http://www.davidfaure.fr
>>>> Working on KDE, in particular KDE Frameworks 5
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrea Diamantini
>>> WEB: http://www.adjam.org
>>>
>>> rekonq project
>>> WEB: http://rekonq.kde.org
>>> IRC: rekonq at freenode
>>>
>>>
>>>
>>
>
>
> --
>
>
> Andrea Diamantini
> WEB: http://www.adjam.org
>
> rekonq project
> WEB: http://rekonq.kde.org
> IRC: rekonq at freenode
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121219/dfd73fe9/attachment.htm>