[webkit-qt] Sending XMLHttpRequests from pages loaded from local URLs to web sites.
laszlo.1.gombos at nokia.com
laszlo.1.gombos at nokia.com
Fri Jan 15 15:17:36 PST 2010
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.
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
> 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
> 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...
More information about the webkit-qt