About the access data across the domainUsing Web.Network.CreateRequest API?
Hi All,
In my gadget developing process, I have to consume web service from a different domain for gadget.start.com or live.com.
so I met the issue, when my gadget published in third-party, and user want to use it, he has to change IE security level and set 'access data across domain' enable!
Through the study, I found this restriction just come out when I use Web.Network.Type.XMLPost to invoke webservice and get response. For other request sending type(XML,XMLGet), it needn't change IE settings. So I hope Some guys can give me some advice on solution or more explaination, I think a gadget always pop up access denied or ask user to dropdown security level is not a successful production...
Thanks in advance
pluto
That's expected. The XMLPost type has not yet been proxied, so it's essentially doing a normal XmlHTTPRequest call. Since XHR calls can't go cross-domain, you get this access restriction. createRequest solves this for XMLGet by calling a proxy that's on the start.com domain like your gadget, so no access violation.
I suggest that you try not to use XMLPost. If you're making a SOAP call, see if you can enable HTTP-GET on your SOAP service (ASP.NET can do this, but some other SOAP implementations like nuSOAP for PHP can't). Alternatively, you may need to rewrite your service to use a RESTful GET interface instead.
BTW, you'd run into this same issue even if you were able to get your gadget certified to run inline, so this is not a limitation only on third-party developers.
What about my case? I'm not using any webservice at the server. i want to post the data to an ASP page. But the
"ACCESS DENIED" javascript error is troubling me. When i debug the gadget from VS 2005 i can see that XMLPost is internally coverted to XMLHTTP object post where the error is raised.. What about the proxy concept in the Gadget framework?
For the time being i can manage with XMLGet but Post is what i ideally want. Solution please (if any? )
A POST is a POST is a POST. If you need to post data via HTTP POST, you'll run afoul of this bug/feature. A POST-based SOAP web service is the canonical example of a failure scenario with this problem, but anything that tries to use HTTP post will fail with "access denied" because POST calls are not proxied.
