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 _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
