[webkit-qt] Sending XMLHttpRequests from pages loaded from local URLs to web sites.

Simon Hausmann 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
>  qt_drt_resetOriginAccessWhiteLists();
> 
> 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
>  proposal:

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
> {
>      DontIncludeSubdomains,
>      IncludeSubdomains
> } 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
>  page->securityOrigin()->addToWhiteList(QUrl(http://*.google.com"),
>  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:

frame->securityOrigin()->addToWhiteList("http", "*.google.com", 
QWebSecurityOrigin::AllowSubDomains);

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?

QWebSecurityOrigin::DomainAccess access;
access.source
access.scheme = "http";
access.domain = "*.google.com";
access.includeSubDomains = true;

QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80", 
access);


The alternative remains the big long one, just for comparision:

QWebSecurityOrigin::addGlobalAccessFromOrigin("http://foo.webkit.org:80", 
"http", "*.google.com", QWebSecurityOrigin::AllowAccessToSubDomains");


Granted, only few developers will ever write this...

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100108/2d205812/attachment.bin>


More information about the webkit-qt mailing list