Tags: ajax, aspnet, denied, error, method, net, permission, xmlhttprequest

XMLHttpRequest open method gives permission denied error.


6,059 words with 12 Comments; publish: Tue, 01 Jan 2008 11:17:00 GMT; (10046.88, « »)

XMLHttpRequest open method gives permission denied error.

All Comments

Leave a comment...

    • Are you posting to a different domain? You will get a permission denied error if you initiate a XMLHttpRequest to a domain other than the one the page is called from. It is by design. There are ways around this, but not using the XMLHttpRequest object.
      #1; Tue, 01 Jan 2008 11:18:00 GMT
    • Could you provide more details about what you are doing? Are you using Atlas, or calling XMLHttpRequest directly?

      #2; Tue, 01 Jan 2008 11:19:00 GMT
    • Hi,

      I got thesolution for it XMLHttpRequest open methos gives error when posted to a different domain other then the one called from .The solution i applied is that i was calling a domain which was already in my trusted set of sites but it was being called from local service , so i addedhttp://localhost as my trusted site .It started working. Is this appropriate solution kindly tell.

      Thank and regards,

      Communty Lover

      #3; Tue, 01 Jan 2008 11:20:00 GMT
    • I am getting the exact same error, and am not requesting a web service on another domain. I'm using Atlas, and calling a web service that is local to the web application. IE gives a "Permission denied" error, while Firefox gives a slightly more descriptive message: "Error: uncaught exception: Permission denied to call method XMLHttpRequest.open". I'm not using any SSL either.


      #4; Tue, 01 Jan 2008 11:21:00 GMT
    • That is strange. How are you referring to your web service in your aspx page? Try using a relative path (e.g. "services/test.asmx") to make sure there is no domain discrepency. Note that when working on your local machine, referring to it as 'localhost' vs 'yourmachine' name is treated as different domains by IE, even though it's the same machine.
      #5; Tue, 01 Jan 2008 11:22:00 GMT
    • I already use a relative path.

      <atlas:ServiceReference Path="Services/EmailFlyerReportListLookup.asmx" Type="text/javascript" /

      Actually, I just tried it with the "Walkthrough: Creating a Basic ASP.NET 'Atlas' Web Application" and it doesn't work either. Same error.

      Now, in the event log, I get this occasionally:

      Event code: 3005

      Event message: An unhandled exception has occurred.

      Event time: 2/9/2006 1:05:18 PM

      Event time (UTC): 2/9/2006 7:05:18 PM

      Event ID: a1c690d50aad4624935d9ecbc9a2172c

      Event sequence: 12

      Event occurrence: 1

      Event detail code: 0


      Exception information:

      Exception type: InvalidOperationException

      Exception message: Request format is unrecognized for URL unexpectedly ending in '/js/'.

      I can't seem to make it happen on any consistent basis, however. I'll play around a bit more and see.

      #6; Tue, 01 Jan 2008 11:23:00 GMT
    • If the walk through doesn't work for you, then there is probably something different about how your machine is set up.

      I would try debugging in Atlas code to see exactly what's getting passed to XmlHttp.

      #7; Tue, 01 Jan 2008 11:24:00 GMT
    • Kindly follow the following steps

      (a)In Internet Explorer-->Tools->Internet Options->Security->Trusted Sites.

      (b)Addhttp://localhost in your trusted site.

      Hope this will work out for u.


      Community Lover

      #8; Tue, 01 Jan 2008 11:25:00 GMT
    • Well, I'm not sure what you mean. On the webserver or on the client? If it's a client setting, then there is obviously an issue with Atlas because I shouldn't have to do that on every computer that might hit this website. Setting this on the server has no effect.

      Now, I've done a bit more research and found that theonly circumstances in which this whole thing doesn't work is when I access the web application via a full, external URL (http://www.whatever.com). If I access the site locally on the server (http://localhost:port), it works fine. Accessing the site from another computer on the same network (http://server:port) works fine as well.

      If this is something that needs handed off to the IIS people, feel free to let me know - I'm out of ideas.

      #9; Tue, 01 Jan 2008 11:26:00 GMT
    • Okay, a little bit more information in an attempt to resolve this issue, because it's killing me.

      Summary of symptoms:

      Using VS05 and the Atlas Template.

      I'm using the first walkthrough available on this site.

      The code is unaltered from the sample.

      Running the site locally produces the desired results in both IE and Firefox.

      Publishing the site to a webserver and accessing the page via http://server:port/script.aspx works.

      Accessing the published site via http://localhost:port/script.aspx works locally on the webserver.

      Accessing the published site via http://host.domain.com/script.aspx does not work, and gives the permission denied errors.

      Publishing the site to a completely different webserver (different domain, network, etc) and accessing via http://host.domain.com/script.aspx works just fine.

      Things we know:

      There is nothing wrong with the Atlas code, because it works fine locally on three different IIS servers.

      The websites on the two servers are configured very similar, with the only difference being that one is hosted on port 80, the other on port 8085.

      No SSL is being used, so it's not a matter of accessing a secure page from a non-secure page.


      The only oddity in the configuration between the two servers is that the server that doesn't work properly with external URLs is being published through an ISA 2000 server. Is there any chance that this is the cause for the permission issue?

      I appreciate any more help on this - I'm completely at a loss, and this technology holds great promise for us.

      #10; Tue, 01 Jan 2008 11:27:00 GMT
    • Update to eliminate one of the "differences". I moved the non-working site to port 80. No change in behavior.

      This almost singles-out the ISA server as mucking with the request. Thoughts?

      #11; Tue, 01 Jan 2008 11:28:00 GMT
    • Anyone have any thoughts on the possibility that routing through the ISA server is breaking the origin?

      I can't believe that I'm the only one who has tried to route Atlas through an ISA server before.

      #12; Tue, 01 Jan 2008 11:29:00 GMT