IInternetSecurityManager URLACTION_CROSS_DOMAIN_DATA and Asynchronous Pluggable Protocol for cross domain XMLHTTP requests in webbrowser control

Question

I've implemented async pluggable protocol in a .net 2.0 application using C# which loads html files stored on the local machine into a MemoryStream.

when I load the html files normally in the webbrowser control using their local file paths, xmlhttprequest works fine but loading the files through the protocol and an attempt to use xmlhttprequest returns an access denied error.

I presume that this behavior is due to the webbrowser control no longer knowing that the html files are stored on the local machine, and is loading them in an untrusted internet zone.

Even though I'm returning S_OK for URLACTION_CROSS_DOMAIN_DATA inside IInternetSecurityManager's ProcessUrlAction which I checked with a break point to make sure it was fired, my IInternetSecurityManager's return value for this action is being ignored.

I've tried setting pdwZone to tagURLZONE.URLZONE_LOCAL_MACHINE in IInternetSecurityManager's MapUrlToZone for my protocol URLs and played around a little with GetSecurityId although I'm not sure exactly what I'm doing with and broke other things like allowing scripts to load etc... Nothing seems to work to allow cross-domain xmlhttprequest.

Anyone any idea how I can get this to work.

Answer 1

Not really an answer, but it may help to isolate the problem. I'd first implement this APP handler in C++ and test it with some robust unmanaged WebBrowser ActiveX host sample, like Lician Wishick's Webform:

http://www.wischik.com/lu/programmer/webform.html

If I could get it working reliably with the unmanaged host, I'd proceed with C# implementation.

I'd also try setting FEATURE_BROWSER_EMULATION to 8000 or less, to impose emulation of legacy IE behavior, just to check if it works that way.

That said, I wouldn't hold my hopes high. I've done my share of WebBrowser/MSHTML integration in the past, and I have a feeling that the APP support hasn't been regression-tested since IE9, in favor for new IE stuff aimed to embrace open web standards.

Updated, MSDN vaguely mentions this:

Upon successful completion, pbSecurityId contains the scheme, domain, and zone information, as well as whether the specified pwszUrl was derived from a Mark of the Web.

Here's the format which worked for me long ago (perhaps, way before "Mark of the Web" was introduced):

static const char security[] = "https:www.mysite.com\2\0\0"; // C++ puts the termination \0 for us

I believe, 2 stands here for the "Trusted Sites" zone. Other zones can be found here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones

Hope this helps.

Answer 2

Maybe I'm wrong but, have you tried to send in your protocol headers Access-Control-Allow-Origin: *?