[Webkit-unassigned] [Bug 45455] [Qt] Support third-party cookie policy for Qt clients
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Apr 4 11:31:55 PDT 2011
https://bugs.webkit.org/show_bug.cgi?id=45455
Robert Hogan <robert at webkit.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter.hartmann at nokia.com
--- Comment #16 from Robert Hogan <robert at webkit.org> 2011-04-04 11:31:54 PST ---
Yesterday I looked into this again with a view to making it a QWebSetting and discovered that the major blocker is distinguishing the top-level domain in a url. If you can't do this, you end up blocking cookies from different hosts rather than different registry-controlled domains.
Fortunately I discovered Peter Hartmann already done all the hard work by adding a hash table based on the public suffix list to QtNetwork, used privately by QNetworkCookieJar.
Since it seems best to keep the policy logic outside QtNetwork (otherwise
you end up having to communicate both the policy and the first-party url
from QtWebKit via the QNetworkRequest) the most effective way of making use
of Peter's TLD table seems to me to be through something like
QUrl::topLevelDomain(). This would allow QtWebKit make a proper comparison
between urls to establish if they are from the same registry-controlled
domain. It would also be a natural fit with QUrl's current API which is able
to dissect every other component of the url.
The downside is that the hash table has to get included through a wrapper
into a QtCore class (ie QUrl) and as a consequence even ends up in the
qmake binary, growing it by 100K.
This is my first hack at creating the required QUrl::topLevelDomain() and sharing the table between QtNetwork and QtCore:
https://gist.github.com/900765
(I've snipped the move of the hash table to a qurltlds_p.h file in that
paste so that it isn't thousands of lines long).
I've pm'd Peter for his thoughts. If anyone thinks I'm going about it all wrong please shout!
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list