locked
InvokeScript Security Exception RRS feed

  • Question

  • Hi,

    We have an app at apptest.mydomain.com and it contains a browser control that loads a html page at helpdesk.mydomain.com and we are getting a security exception.

    Surely this is possible? Surely we don't need a clientaccesspolicy file since we are on the same domain, just different subdomains?

    So we added a clientaccesspolicy file, same error.

    The documentation says if different domains you cannot invokescript:

    http://msdn.microsoft.com/en-us/library/cc491132(v=vs.95).aspx

    Do they mean TOP level domains being different or any level of domain?

    Monday, June 6, 2011 5:43 PM

Answers

  • The definition of "cross domain" is the same, but you are right. The policy only affects services and other forms of communication, not client-side scripting access. Which means you cannot solve this with a policy file.

    To be honest I'm sometimes not sure which of these (client-side) restrictions originate in Silverlight, and which ones are built into the browsers. For example, script access to cross-domain content in iFrames etc. is something browsers forbid for non-Silverlight content too.

    Edit: I just remembered this - there's a document.domain property that can be used to resolve subdomain conflicts with cross-domain checks. I think that maybe you can solve your problem using this too.

    Tuesday, June 7, 2011 7:46 AM

All replies

  • Hi.

    Surely we don't need a clientaccesspolicy file since we are on the same domain, just different subdomains?

    Do they mean TOP level domains being different or any level of domain?

    Cross-domain in the terms of Silverlight's security means any difference in the sub domain, protocol and even port. This is a bit hidden in the docs, but can be found e.g. here:

    Same domain means that calls must use the same sub domain, protocol, and port.

    Which means you cannot execute JavaScript if it's on a different sub domain. If you think about it, that's a relevant issue with e.g. shared hosting or similar, where you indeed can have unrelated content on different sub domains that needs to be isolated.


    Tuesday, June 7, 2011 12:49 AM
  • Which means you cannot execute JavaScript if it's on a different sub domain. If you think about it, that's a relevant issue with e.g. shared hosting or similar, where you indeed can have unrelated content on different sub domains that needs to be isolated.

    Thanks for confirming this and especially for the link - I agree it is buried somewhat, so great find, thank you.

    So shouldn't a clientaccesspolicy file solve this problem and allow the script to invoke? Or is that action just not allowed, period, on different domains/subdomains? The reason I ask is because we added a crossdomainpolicy file to the target domain and it did not solve the issue [could it be that the target domain is Azure and something about the Azure configuration is preventing the invoke?]

    The other reason I ask is because all the documentation (including what you linked) ever seems to talk about is calling services on other domains, which we are not doing; we are trying to invoke a script on a page on another subdomain.

    Thanks,

    Richard

    Tuesday, June 7, 2011 5:59 AM
  • The definition of "cross domain" is the same, but you are right. The policy only affects services and other forms of communication, not client-side scripting access. Which means you cannot solve this with a policy file.

    To be honest I'm sometimes not sure which of these (client-side) restrictions originate in Silverlight, and which ones are built into the browsers. For example, script access to cross-domain content in iFrames etc. is something browsers forbid for non-Silverlight content too.

    Edit: I just remembered this - there's a document.domain property that can be used to resolve subdomain conflicts with cross-domain checks. I think that maybe you can solve your problem using this too.

    Tuesday, June 7, 2011 7:46 AM
  • The definition of "cross domain" is the same, but you are right. The policy only affects services and other forms of communication, not client-side scripting access. Which means you cannot solve this with a policy file.

    To be honest I'm sometimes not sure which of these (client-side) restrictions originate in Silverlight, and which ones are built into the browsers. For example, script access to cross-domain content in iFrames etc. is something browsers forbid for non-Silverlight content too.

    Edit: I just remembered this - there's a document.domain property that can be used to resolve subdomain conflicts with cross-domain checks. I think that maybe you can solve your problem using this too.

    Thank you for confirming what I suspected was the case. We did manage to solve this by using a javascript library using sockets to send the data to script on the other subdomain after first invoking it on the Silverlight's host domain. Messy, not great to maintain going forward, but it worked.

    The document.domain property looks like it will work. When I have time I will test that and post back. I'm marking that post as the answer, since you did answer my main question, which was about invoking script in a cross-domain setting.

    Thanks for the help!

    Richard

    Tuesday, June 7, 2011 9:40 AM