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 <[email protected]> wrote: > On Fri, Mar 18, 2011 at 10:46 PM, Joe Andrieu <[email protected]> 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 >> [email protected] >> +1 (805) 705-8651 >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
