On Thu, Jan 6, 2011 at 10:17 PM, Pushparajan V <vpra...@gmail.com> wrote: > On Fri, Jan 7, 2011 at 1:18 AM, Adam Barth <aba...@webkit.org> wrote: >> On Thu, Jan 6, 2011 at 6:27 AM, Pushparajan V <vpra...@gmail.com> wrote: >>> I have a query regarding addOriginAccessWhitelistEntry API in >>> SecurityOrigin.cpp. Is there any special requirement in the >>> sourceOrigin argument of this API when the scheme of the sourceOrigin >>> is already added to the localScheme list? >> >> There's a long-standing issue here that some of the checks for >> whitelisting and being local are backwards. I tried to fix this >> recently, but that caused a performance regression because the >> canDisplay method is apparently very hot in the page load test. I >> need to circle back and give it another shot. >> >>> Because if the sourceOrigin is localScheme and the URI doesn't have a >>> path, this API fails miserably without any warning or asserts. >> >> Sorry. :( >> >>> For example, if widget is a local scheme and the source origin URI is >>> widget://884889/ for which i need to whitelist some destination URLs, >>> the below statement returns null. >>> >>> String sourceString = sourceOrigin.toString(); >> >> That behavior is actually correct. By default, we treat local origins >> as if the were sandboxed with the unique origin bit. What's your >> motivation for marking widget as a local origin? > > Since widget accesses files in local filesystem, this marking is done. > As you said, this new unique origin bit used for sandboxing is the > reason behind null getting returned by toString.
Hum... I'm not really sure what a widget is, but allowing access to the local filesystem is very dangerous. >> The same change I mentioned above is mostly concerned with >> crystalizing out the two properties we have tied up in "localness," >> which are blocking navigation to local URLs and special access status >> for them (historically universal access, more recently sandboxed >> access). > > There is a fear of losing compatibility with the latest HTML5 > localSchemes like data://, sandbox:// etc. That's the reason widget > scheme wanted to be kept as local. data isn't a local scheme in HTML5. We need to charge some architectural things in WebKit to be able to implement data URLs as specified in HTML5. I've never heard of a sandbox URL scheme. >>> After debugging more, found that all local schemes are treated as >>> file:// schemes and directory access is not allowed for any >>> localScheme. >> >> Yeah, I think that's what I meant above by "sandboxed" but I could be >> misunderstanding. >> >>> Does that mean securityOrigin's should be created always with full URLs? >> >> You can't round-trip SecurityOrigin objects via toString. There are >> several things that aren't represented in the string version, >> including document.domain and the HTML5 sandbox bits. >> >> I'm not 100% sure I answered your question, but I suspect the solution >> might be to avoid marking widget as a local scheme. > > Yeah that would be the perfect fix. Moreover, this is what tried out > recently and working well. Great. That should make things less magical for you. > But the only problem suspected with this is blocking of > navigation/access with other internal localSchemes (like file, data). > Need to test and study that flow as well to come with a conclusion. Data URLs should be no problem. Blocking navigation to file URLs is likely a benefit. :) > Thanks Adam. It answered many of my questions in one shot. :) Good luck! Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev