Allow "cross-origin" XHR requests for non-standard URLs?
On Sat, Mar 19, 2011 at 6:46 AM, Joe Andrieu <joe@andrieu.net> wrote:
I've been working with the Chromium Embedded Framework (in windows) which gives webkit version 534.20. I am trying to get a custom scheme to work with XHR.
By way of background, I first updated the Cef code so that custom schemes can be declared "non-standard", which avoids certain parsing errors. Non-standard schemes include "data", "javascript", "file". Webkit has a mechanism for registering standard schemes, so all I needed to do was /not/ register custom schemes that were non-standard.
Just curious of your use case, do you really need non-standard scheme? Wouldn't it be easier to just define a custom scheme? I see people do that all the time with QtWebKit for hybrid apps. cheers, Benjamin
On Sat, Mar 19, 2011 at 10:56 AM, Joe Andrieu <joe@andrieu.net> wrote:
Well, I am defining a custom scheme. But its semantics are not hierarchical and do not have the typical authority-part that allows cross-origin checks to make sense. Because of that, WebKit's CanonicalizeURL fails if my scheme is registered as standard. Which makes sense, because it isn't standard.
I'm not familiar with QtWebKit's integration. From the first couple of web pages Google brought up, it isn't clear that their protocols will actually work with AJAX / XMLHttpRequest. There are no examples of doing it, and from walking through the WebKit code, I'm skeptical a stock version of WebKit would allow it.
With a valid scheme, XMLHttpRequest, cross origin or not, can be made to work without changing WebKit. But if your scheme is non standard that does not gonna for the reason you describe. My suggestion is just to use a standard scheme to avoid patching WebKit. It is no uncommon to use a valid scheme internally, and display something else in the interface. Rekonq new-tab-page branch uses rekonq:// internally, and "about:" for display. Chromium uses chrome:// for its internally as well (for example, about:version is chrome://about/version). cheers, Benjamin
On Fri, Mar 18, 2011 at 10:46 PM, Joe Andrieu <joe@andrieu.net> wrote:
I've been working with the Chromium Embedded Framework (in windows) which gives webkit version 534.20. I am trying to get a custom scheme to work with XHR.
By way of background, I first updated the Cef code so that custom schemes can be declared "non-standard", which avoids certain parsing errors. Non-standard schemes include "data", "javascript", "file". Webkit has a mechanism for registering standard schemes, so all I needed to do was /not/ register custom schemes that were non-standard.
My custom scheme works fine at the beginning of the request. Chromium/Cef successfully calls my scheme handler and my response data is read. But it fails when the DocumentThreadableLoader::DocumentThreadableLoader constructor starts checking for cross-origin security.
I was able to get the code to "work" by bypassing the origin tests and simply calling "loadRequest" in that constructor.
As a fix, I'd like to propose that non-standard scheme URLs be accessible from any security origin.
I'm afraid this would be a security vulnerability. It would be very dangerous to default unusual schemes to be accessible from any security origin. :( I'm not entirely sure what you're trying to do, but it's likely to can return CORS headers from your custom URL handler that allow access from every security origin. Adam
A patch to SecurityOrigin::canRequest could set DocumentThreadableLoader::m_sameOriginRequest to true if url_util::DoIsStandard returns false. This would use Webkit's existing whitelist mechanism for standard schemes. If necessary, exclusions could be hardcoded if certain non-standard schemes are inappropriate for this policy.
Since this could have significant security implications, I wanted to run it by here first.
I realize that my use case is stretching XMLHttpRequest well past http, but this would allow using custom schemes with libraries that support AJAX requests, such as JSTree.
Curiously enough, I ran into the "rdar" scheme in the code, referencing Apple's internal bug database. Given the current webkit security policy, it would be impossible to access rdar URLs via Ajax. My proposed change would allow it (assuming an appropriate scheme handler is available).
FWIW, I'd be happy to figure out and provide a patch.
-j
-- Joe Andrieu joe@andrieu.net +1 (805) 705-8651
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
I should also say, please feel free to grab me on #webkit can we can try to find a solution for you more interactively. Adam On Sat, Mar 19, 2011 at 6:53 AM, Adam Barth <abarth@webkit.org> wrote:
On Fri, Mar 18, 2011 at 10:46 PM, Joe Andrieu <joe@andrieu.net> wrote:
I've been working with the Chromium Embedded Framework (in windows) which gives webkit version 534.20. I am trying to get a custom scheme to work with XHR.
By way of background, I first updated the Cef code so that custom schemes can be declared "non-standard", which avoids certain parsing errors. Non-standard schemes include "data", "javascript", "file". Webkit has a mechanism for registering standard schemes, so all I needed to do was /not/ register custom schemes that were non-standard.
My custom scheme works fine at the beginning of the request. Chromium/Cef successfully calls my scheme handler and my response data is read. But it fails when the DocumentThreadableLoader::DocumentThreadableLoader constructor starts checking for cross-origin security.
I was able to get the code to "work" by bypassing the origin tests and simply calling "loadRequest" in that constructor.
As a fix, I'd like to propose that non-standard scheme URLs be accessible from any security origin.
I'm afraid this would be a security vulnerability. It would be very dangerous to default unusual schemes to be accessible from any security origin. :(
I'm not entirely sure what you're trying to do, but it's likely to can return CORS headers from your custom URL handler that allow access from every security origin.
Adam
A patch to SecurityOrigin::canRequest could set DocumentThreadableLoader::m_sameOriginRequest to true if url_util::DoIsStandard returns false. This would use Webkit's existing whitelist mechanism for standard schemes. If necessary, exclusions could be hardcoded if certain non-standard schemes are inappropriate for this policy.
Since this could have significant security implications, I wanted to run it by here first.
I realize that my use case is stretching XMLHttpRequest well past http, but this would allow using custom schemes with libraries that support AJAX requests, such as JSTree.
Curiously enough, I ran into the "rdar" scheme in the code, referencing Apple's internal bug database. Given the current webkit security policy, it would be impossible to access rdar URLs via Ajax. My proposed change would allow it (assuming an appropriate scheme handler is available).
FWIW, I'd be happy to figure out and provide a patch.
-j
-- Joe Andrieu joe@andrieu.net +1 (805) 705-8651
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (3)
-
Adam Barth
-
Benjamin
-
Joe Andrieu