Safely avoiding the "access denied" dialog [How to: Work around the access denied cross-domain IFRAME issue in the AJAX Control Toolkit]

This blog has moved to a new location and comments have been disabled.

All old posts, new posts, and comments can be found on The blog of

See you there!

Comments (27)
  1. 在iframe或frame中使用另一个域名的ASP.NETAJAX或Toolkit页面,会得到cross-domainaccessdenied错误。Bleroy

  2. says:

    在iframe或frame中使用另一个域名的ASP.NET AJAX或Toolkit页面,会得到cross-domain access denied错误。 Bleroy 和 Delay 分别post了两篇文章,详细讲述了引起问题的原因以及如何解决。如果你也遇到了这个问题可以参考。

  3. guyinfun says:

    Thanks for the solution. It worked on IE7 but IE6 is still giving me the same errors.

  4. David Anson says:


    I probably should have been more explicit. The changes I describe above are for the AJAX Control Toolkit *only*. You’ll *also* need to make the changes Bertrand describes for your ASP.NET AJAX install.

    Please note that the next release of the Toolkit will include the changes described here, so you shouldn’t need to patch the Toolkit again after our next release. (Though the modifications to your ASP.NET AJAX installation will still be needed.)

    Hope this helps!

  5. Romeo Pruno says:

    Veramente il problema è più generale e riguarda un bug della versione 1.0 di AJAX, come segnalato anche

  6. RalphCEO says:

    case Sys.Browser.InternetExplorer:

       Sys.UI.DomElement.getLocation=function Sys$UI$DomElement$getLocation(a)



           return new Sys.UI.Point(0,0);

         var d = a.getClientRects();

         if(!d || !d.length)

           return new Sys.UI.Point(0,0);

         var inFrame = false;

         // Get the first bounding rectangle in screen coordinates

         var screenRects = element.getClientRects();

         if (!screenRects || !screenRects.length) {

             return new Sys.UI.Point(0,0);


         var first = screenRects[0];

         // Delta between client coords and screen coords

         var dLeft = 0;

         var dTop = 0;



           inFrame = a.ownerDocument.parentWindow.frameElement;




           inFrame = true;




           var e=a.ownerDocument.parentWindow;

           var g=e.screenLeft – top.screenLeft – top.document.documentElement.scrollLeft + 2;

           var h=e.screenTop – top.screenTop – top.document.documentElement.scrollTop + 2;

           var c=e.frameElement||null;



             var b=c.currentStyle;

             g+=(c.frameBorder||1) * 2 + (parseInt(b.paddingLeft) || 0) + (parseInt(b.borderLeftWidth) || 0) – a.ownerDocument.documentElement.scrollLeft;

             h+=(c.frameBorder||1) * 2 + (parseInt(b.paddingTop) || 0) + (parseInt(b.borderTopWidth) || 0) – a.ownerDocument.documentElement.scrollTop;


           var f=d[0];

           return new Sys.UI.Point(f.left-g,;




           // Get the bounding rectangle in client coords

           var clientRect = element.getBoundingClientRect();

           if (!clientRect)


             return new Sys.UI.Point(0,0);


           // Find the minima in screen coords

           var minLeft = first.left;

           var minTop =;

           for (var i = 1; i < screenRects.length; i++)


             var r = screenRects[i];

             if (r.left < minLeft)


               minLeft = r.left;


             if ( < minTop)


               minTop =;



           // Compute the delta between screen and client coords

           dLeft = minLeft – clientRect.left;

           dTop = minTop –;

           // Subtract 2px, the border of the viewport (It can be changed in IE6 by applying a border style to the HTML element,

           // but this is not supported by ASP.NET AJAX, and it cannot be changed in IE7.), and also subtract the delta between

           // screen coords and client coords

           var ownerDocument = element.document.documentElement;

           return new Sys.UI.Point(first.left – 2 – dLeft + ownerDocument.scrollLeft, – 2 – dTop + ownerDocument.scrollTop);




  7. ojaytee says:


    I am having the Access Denied javascript error, but the it only happens on our integration server.  This only happens when the page has been left unattended for a while.  This happens on IE 6 & 7.

    I tried your fix, but I still have the same problem.

    Below is the code that breaks:

    switch(Sys.Browser.agent) {

       case Sys.Browser.InternetExplorer:

           Sys.UI.DomElement.getLocation = function Sys$UI$DomElement$getLocation(element) {

               /// <param name="element" domElement="true"></param>

               /// <returns type="Sys.UI.Point"></returns>

               var e = Function._validateParams(arguments, [

                   {name: "element", domElement: true}


               if (e) throw e;

                           if (element.self || element.nodeType === 9) return new Sys.UI.Point(0,0);

                                                   var clientRects = element.getClientRects();

               if (!clientRects || !clientRects.length) {

                   return new Sys.UI.Point(0,0);


               var w = element.ownerDocument.parentWindow;

                                                   var offsetL = w.screenLeft – top.screenLeft – top.document.documentElement.scrollLeft + 2;

               var offsetT = w.screenTop – top.screenTop – top.document.documentElement.scrollTop + 2;

                                                                           var f = w.frameElement || null;

               if (f) {

                                                                                   var fstyle = f.currentStyle;

                   offsetL += (f.frameBorder || 1) * 2 +

                       (parseInt(fstyle.paddingLeft) || 0) +

                       (parseInt(fstyle.borderLeftWidth) || 0) –


                   offsetT += (f.frameBorder || 1) * 2 +

                       (parseInt(fstyle.paddingTop) || 0) +

                       (parseInt(fstyle.borderTopWidth) || 0) –



    Any help will be appreciated.


  8. David Anson says:


    If you’re having to patch the Toolkit, then you’re probably on a fairly old release. I’d recommend upgrading to a more recent Toolkit version like the 10920 release. However, what seems more likely to be the issue is that the code you pasted is ASP.NET AJAX (not Toolkit) code that does not appear to have been patched per the instructions at I’m guessing that someone patched most of your servers but missed the problematic integration server somehow.

    Hope this helps!

  9. ojaytee says:

    Hi! Delay,

    Thanks for your promp response.  I very new to AJAX and some og my questions may sound a bit dull.

    Just a few questions:

    1. Is it normal for this issue to occur only when the page has been left unattended for a while.  

    2. I had chat with our server administrator, who is not even aware of this issue and he mentioned that the AJAXExtensionsToolbox.dll does not exist in the ASP.NET 2.0 AJAX Extensionsv1.0.61025 directory on the server.  Do we need the toolkit on the server as well or the DLLs will be deployed the the server with the application.

    3. The other issue is that we have other applications running on the very same server, but they are not affected by this issue.  These applications are using the same architecture.  How could this only affect our application?

    I will ask our server admin to apply the patch and feed you back the results.



  10. David Anson says:


    1. I’m not sure why this would be more likely if the page has been left unattended as it’s my understanding the problem is either present or not. One thing that I wonder about is if you’re load-balancing and the delay causes a different server to be hit? (One that wasn’t patched.)

    2. I can’t speak for the ASP.NET AJAX patching process, but regarding proper AJAX Control Toolkit install, all it takes is for AjaxControlToolkit.dll to be in your web site’s /Bin directory (on all web servers).

    3. As I recall, the ASP.NET AJAX patching process ends up being per-application because of the way it requires modifying the way ScriptManager is defined/used in your pages.

  11. andrea81 says:


    i’m in production with an application written in ASP.NET 2.0 (Ajax Enabled) and we have this problem.

    Since issue is know and i read that for Orcas has been fixed, is there similar fix (into the DLL) release from MS to support people that develop application AJAX Enabled with ASP.NET 2.0?

    Thanks a lot,


  12. David Anson says:


    I believe that the official ASP.NET AJAX 2.0 patch is detailed in the blog I link to in my original post:

  13. andrea81 says:

    Hi Delay,

    yes, i read the post some weeks ago but i wrote you because i also read :

    "This fix implies that you stop using the resource-based scripts and use the static file versions instead.  I expect this is the fix that will be in the next service release, so when the next release of System.Web.Extensions happens, you will want to revert to using the resource-based scripts to get any other fixes or changes that are made."

    So because the post was written in 31 January i beleave that a release version (not a workaround)of "System.Web.Extensions"  was now present for people that use AJAX in ASP.NET 2.0.

    Thank you very much.


  14. David Anson says:


    The latest ASP.NET AJAX release was created in mid-January based on the dates in my C:Program FilesMicrosoft ASP.NETASP.NET 2.0 AJAX Extensionsv1.0.61025 directory. I’m not aware of any subsequent releases, so the advice Bertrand gave should still be relevant today.

    Please note that there is a new ASP.NET AJAX release coming as part of .NET 3.5 which should be finalized sometime in the coming months. I can’t say for sure whether this particular issue was addressed there (check with Bertrand to be sure), but I’d expect that it was.

  15. so i went and downloaded the new ajax toolkit 10920 from codeplex. I was still getting the error so i

  16. kfsone says:

    The Cross-Domain issue with Ajax has bothered me for a while, it limits Ajax to a thin-client role and prevents Ajax from fulfilling the syndication niche – where what I want is <i>expressly</i> to allow others to direct data requests to me from their sites.

    It strikes me that the solution is really very simple: Change XMLHttpRequest to request the specified document, but if the server does not return an "XMLHttpRequest: Allowed", then perform the current behavior.

    You could even have XMLHttpRequest provide a specific header – e.g. "XMLHttpRequest: {originating page}" in the GET/POST request so that the remote server can respond accordingly: e.g. it might return an annotated XML file including comments when someone queries an XML file directly from their browser, but sends a more compact version otherwise.

  17. David Anson says:


    I don’t have enough context to comment on your idea, but if you post it to the "ASP.NET AJAX Discussion and Suggestions" forum at, the people there can probably give you a lot of great feedback!

  18. iulia says:

    Cross domain calls by means of iframe – IE Browser restrictions and solutions All modern web browsers

  19. So I tend to describe a lot of issues here, but we had some really great conversation in our blog chat.&#160;

  20. Thempra.NET says:

    Uno de los grandes problemas que tenemos en lo referente a seguridad web, son los temido ataques "cross-site

  21. . says:

    lank_page Uno de los grandes problemas que tenemos en lo referente a seguridad web, son los temido ataques

  22. piris says:

    RalphCEO's comment works

  23. SDG says:

    Query about sidestepping the whole problem by simply not using cross-domain frames: Will it resolve the problem if the framed site using Ajax uses a subdomain alias of the host page domain? E.g., if I use Ajax on a page hosted at, and I display that site in an iframe on a page at, will this avoid the issue?

  24. David Anson says:


    I'm afraid I'm not sure – enough has changed since I wrote this post that I'm sure anything I remember about this is at least partially wrong. Per the above, both ASP.NET AJAX and the AJAX Control Toolkit should have been fixed (or be easily fixable), so I'm hopeful this doesn't need to be much of a concern anymore!

Comments are closed.

Skip to main content