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

[laszlo.1.gombos at nokia.com]

Simon,

Carol & I discus this a bit more. 

"GlobalAccess" in the name is a bit misleading as one might relate it to granting all=global access to something, which is not the case.  I think this API works similarly to globalSettings() interface as it sets up access rules for to-be-created pages. I think this should be a static QWebSecurityOrigin function and static also signals that this is "global".

What about "static QWebSecurityOrigin::addAccessFromOrigin(..).". I do not really have an opinion on the arguments, both proposals (big long one and DomainAccess ) looks good to me.

Laszlo


-----Original Message-----
From: webkit-qt-bounces at lists.webkit.org [mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of Hausmann Simon (Nokia-D-Qt/Oslo)
Sent: Friday, January 08, 2010 11:40 AM
To: webkit-qt at lists.webkit.org
Subject: Re: [webkit-qt] Sending XMLHttpRequests from pages loaded from local URLs to web sites.


(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