[webkit-qt] Sending XMLHttpRequests from pages loaded from local URLs to web sites.
simon.hausmann at nokia.com
Fri Jan 8 08:40:21 PST 2010
(Kenneth, Benjamin, Tor Arne, others interested in the API - please comment)
On Monday 21 December 2009 Szabo Carol (Nokia-D/Boston), wrote:
> While allowing pages loaded from one security origin to send
> XMLHttpRequests to URLs located in a different security origin is unsecure
> for various reasons and therefore should be forbidden by default, there
> are legitimate use cases such as those of Offline Applications and Widgets
> that require this feature. WebKit internally supports a static whiteList
> that pairs source security origins with ranges of allowed target security
> origins. This whieList is privately exposed by the QtWebKit Api for the
> use of DumpRenderTree via
> void QWEBKIT_EXPORT qt_drt_whiteListAccessFromOrigin(const QString&
> sourceOrigin, const QString& destinationProtocol, const QString&
> destinationHost, bool allowDestinationSubdomains); void QWEBKIT_EXPORT
> Since the need for this Api appears to be broad and long term I suggest
> making it an official Api. In keeping with other QtWebKit Apis, here is my
I agree, we should try to make it public API.
> In the current QWebSecurity origin add the following members:
> static QWebSecurityOrigin* create(const QUrl&);
> -- This is needed because all current constructors of
> QWebSecurity origin are private and none of them takes a Url as an
> argument. -- Since this pattern is not used in Qt, probably adding a
> public constructor would be more appropriate. Please vote on this.
> typedef enum
> } SubdomainHandling;
> void addToWhiteList(const QUrl&, SubdomainHandling subdomainHandling =
> DontIncludeSubdomains); static void clearWhiteLists();
> -- These functions implement the currently hidden API.
> -- There is a fine point about addToWhiteList:
> qt_drt_whiteListAccessFromOrigin ignores *. at the beginning of the
> hostname, QUrl does not accept host names containing *. This difference in
> behavior must be accounted for in DumpRenderTree when making the
> transition and may be an issue for users, as code like this
> QWebSecurityOrigin::IncludeSubDomains); has the most likely unexpected
> effect of whitelisting all http websites. an alternative is to use a
> version of add to whitelist that is closer to the ultimate implementation:
> void addToWhiteList(const QString& scheme, const QString& host,
> SubdomainHandling subdomainHandling = DontIncludeSubdomains);
With QUrl not accepting "*" in the host name I think it's clear that it's not
the right data type to use.
I remember I opposed to a method that has many arguments, initially. But
looking at the resulting code with a member method I'm inclined to change my
opinion ;-). Let's compare:
By looking at the code one might believe that this only affects the security
origin of the frame, but the call has a global effect!
What about this API?
access.scheme = "http";
access.domain = "*.google.com";
access.includeSubDomains = true;
The alternative remains the big long one, just for comparision:
"http", "*.google.com", QWebSecurityOrigin::AllowAccessToSubDomains");
Granted, only few developers will ever write this...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the webkit-qt