[webkit-qt] Exposing Document::firstPartyForCookies()

[Mohammed Sameer]

On Mon, Jul 12, 2010 at 01:38:49PM +0300, Mohammed Sameer wrote:
> Hi,
> 
> I think exposing that Document::firstPartyForCookies() would be a nice QtWebKit API addition.
> The use case I have in mind is allowing third party cookies filtering.
> 
> Ideally it QNetworkCookieJar should be modified to be:
> bool QNetworkCookieJar::setCookiesFromUrl(const QList<QNetworkCookie>& cookieList, const QUrl& url , const QUrl& firstPartyForCookies = QUrl()) and then QtWebKit should just call it.
> 
> Since I don't dare proposing such a change (Did I just do it ? ;-)) I thought the simplest
> solution would be adding
> QUrl QWebFrame::firstPartyForCookies() const
> 
> What do you think ?
> 
> Here's the bug report:
> https://bugs.webkit.org/show_bug.cgi?id=41996
> 
> I also uploaded a patch there. I know it's missing a test but I'm not adding that
> before an API agreement has been reached.

After talking with Richard Moore (richmoore3) on IRC, we came out with a proposal:
[22:34] <richmoore3> well, a cookie is a response header. so if you listen to the metaDataChanged() signal then you know when the headers arrive
[22:35] <richmoore3> you could then remove the one that you don't want
[22:35] <richmoore3> i'm not saying 100% it is possible this way, but i don't see any immediate barriers
[22:36] <MSameer> it can't be done that way
[22:37] <MSameer> because QNetworkReplyImplPrivate calls jar->setCookiesFromUrl(cookies, url);  then it emits the signal:
[22:37] <MSameer> emit q->metaDataChanged();  
[22:37] <richmoore3> ok, yes that screws that 
[22:37] <MSameer> unfortunately
[22:38] <richmoore3> personally i'd regard that as a bug
[22:38] <richmoore3> working around it would require a proxy cookie jar too and is starting to get silly
[22:38] <MSameer> and complicated
[22:38] <richmoore3> yes

So we could in theory connect QNetworkReply::metaDataChanged to a callback and drop third party cookies there:

QObject *o = qobject_cast<QNetworkReply *>(sender())->request().originatingObject();
QUrl firstParty = qobject_cast<QWebPage *>(o->page())->mainFrame()->url();


Later on:
[22:55] <mgoetz[home]> what do you mean by moving metaDataChanged() ?
[22:56] <MSameer> mgoetz[home]: oid QNetworkReplyImplPrivate::metaDataChanged()  calls QNetworkCookieJar::setCookiesFromUrl() then it emits metaDataChanged()
[22:57] MSameer mgoetz[home] mwenge makulkar manyoso mgoetz misha MSameerWork mulvad 
[22:57] <richmoore3> well, if cookies are put into the jar before we get the meta data signal then we have no chance to change the set-cookie header
[22:57] <MSameer> mgoetz[home]: so if we reverse that, we can manipulate the cookies before they get added to the jar in order to reject third party ones
[23:00] <mgoetz[home]> i doubt that QNAM can be changed. such behaviour changes could break some apps..
[23:00] <richmoore3> mgoetz[home]: i don't see how that particular change could break anything
[23:01] <mgoetz[home]> richmoore3: people depending on cookies being inside the cookie jar in their metaDataChanged slot

-- 
GPG-Key: 0xA3FD0DF7 - 9F73 032E EAC9 F7AD 951F  280E CB66 8E29 A3FD 0DF7
Debian User and Developer.
Homepage: www.foolab.org