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: [email protected] [mailto:[email protected]] On Behalf Of Hausmann Simon (Nokia-D-Qt/Oslo) Sent: Friday, January 08, 2010 11:40 AM To: [email protected] 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 _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
