Welcome to MSDN Blogs Sign in | Join | Help

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

Bertrand recently blogged "How to work around the access denied cross-domain frame issue in ASP.NET Ajax 1.0". Unfortunately, a similar issue exists in the AJAX Control Toolkit - with a similar workaround that's detailed in this post.

Background: The AJAX Control Toolkit attempts to use as much of the ASP.NET AJAX infrastructure as possible in order to keep things simple and benefit from the established architecture of ASP.NET AJAX. However, the ASP.NET AJAX 1.0 implementation of Sys.UI.getLocation was not accurate for IFRAME content with certain page layouts in IE6 - one of which was used by the Toolkit test harness. We couldn't have our automated tests failing - and the ASP.NET AJAX team wasn't able to include a fix in their 1.0 release - so we needed to address this somehow. Since we had developed our own getLocation implementation that was accurate in IE6, we decided to route all Toolkit calls to getLocation through our own wrapper function - which used our improved implementation for IE6 and called through to the ASP.NET AJAX implementation for everything else. This works pretty well - except that our version suffers from the same cross-domain permissions issue that the ASP.NET AJAX version suffers from (please refer to Bertrand's post for more details).

Fix: We've just checked in a fix to the Toolkit's Development branch to add the same try/catch wrapper that Bertrand suggests; this fix will be included with the next Toolkit release (in about a month). In the meantime, people who want the fix sooner are encouraged to apply the changes themselves. To do so, open AjaxControlToolkit.sln in Visual Studio, open the file AjaxControlToolkit\Common\Common.js, find the getLocation function, add the yellow, italic block below, and build the project to get a new AjaxControlToolkit.dll with the fix. The complete function definition with the fix applied is included here to make this as easy as possible:

getLocation : function(element) {
    
/// <summary>Gets the coordinates of a DOM element.</summary>
    /// <param name="element" domElement="true"/>
    /// <returns type="Sys.UI.Point">
    ///   A Point object with two fields, x and y, which contain the pixel coordinates of the element.
    /// </returns>

    // workaround for an issue in getLocation where it will compute the location of the document element.
    // this will return an offset if scrolled.
    //
    if (element === document.documentElement) {
        
return new Sys.UI.Point(0,0);
    }

    
// Workaround for IE6 bug in getLocation (also required patching getBounds - remove that fix when this is removed)
    if (Sys.Browser.agent == Sys.Browser.InternetExplorer && Sys.Browser.version < 7) {
        
if (element.window === element || element.nodeType === 9 || !element.getClientRects || !element.getBoundingClientRect) return new Sys.UI.Point(0,0);

        
// 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;

        var inFrame = false;
        
try {
            inFrame = element.ownerDocument.parentWindow.frameElement;
        }
catch(ex) {
            
// If accessing the frameElement fails, a frame is probably in a different
            // domain than its parent - and we still want to do the calculation below
            inFrame = true;
        }

        
// If we're in a frame, get client coordinates too so we can compute the delta
        if (inFrame) {
            // 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 = first.top;
            
for (var i = 1; i < screenRects.length; i++) {
                
var r = screenRects[i];
                
if (r.left < minLeft) {
                    minLeft = r.left;
                }
                
if (r.top < minTop) {
                    minTop = r.top;
                }
            }

            
// Compute the delta between screen and client coords
            dLeft = minLeft - clientRect.left;
            dTop = minTop - clientRect.top;
        }

        
// 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, first.top - 2 - dTop + ownerDocument.scrollTop);
    }

    
return Sys.UI.DomElement.getLocation(element);
},

Sorry for the trouble - we hope this patch helps any people who might be running into this issue!

Updated at 6pm: Modified the getLocation implementation to return the correct value in all cases.

Published Monday, February 05, 2007 4:46 PM by Delay

Comments

# ASP.NET AJAX 1.0

Wednesday, February 07, 2007 12:22 AM by 出走的影子

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

# ASP.NET AJAX 1.0 & AJAX Control Toolkit 在iframe中的"access denied"错误

Wednesday, February 07, 2007 12:56 AM by cnblogs.com

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

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

Wednesday, February 07, 2007 10:15 AM by guyinfun

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

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

Wednesday, February 07, 2007 2:50 PM by Delay

guyinfun,

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!

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

Friday, February 09, 2007 12:31 AM by guyinfun

# Sharepoint &amp; Ajax, possibili problemi con Cross Domain XmlHttpRequests

Tuesday, March 20, 2007 9:15 AM by Romeo Pruno

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

# 解决ASP.NET AJAX在frame及iframe中跨域访问的问题

Wednesday, July 11, 2007 2:52 AM by 网际飞狐

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

Tuesday, August 21, 2007 12:49 PM by RalphCEO

case Sys.Browser.InternetExplorer:

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

   {

     if(a.self||a.nodeType===9)

       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;

     try

     {

       inFrame = a.ownerDocument.parentWindow.frameElement;

     }

     catch(ex)

     {

       inFrame = true;

     }

     if(!inFrame)

     {

       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;

       if(c)

       {

         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,f.top-h);

     }

     else

     {

       // 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 = first.top;

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

       {

         var r = screenRects[i];

         if (r.left < minLeft)

         {

           minLeft = r.left;

         }

         if (r.top < minTop)

         {

           minTop = r.top;

         }

       }

       // Compute the delta between screen and client coords

       dLeft = minLeft - clientRect.left;

       dTop = minTop - clientRect.top;

       // 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, first.top - 2 - dTop + ownerDocument.scrollTop);

     }

   };

   break;

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

Monday, October 22, 2007 11:26 AM by ojaytee

Hi!

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) -

                   element.ownerDocument.documentElement.scrollLeft;

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

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

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

                   element.ownerDocument.documentElement.scrollTop;

           }

Any help will be appreciated.

Thanks

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

Monday, October 22, 2007 11:53 AM by Delay

ojaytee,

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 http://weblogs.asp.net/bleroy/archive/2007/01/31/how-to-work-around-the-quot-access-denied-quot-cross-domain-frame-issue-in-asp-net-ajax-1-0.aspx. I'm guessing that someone patched most of your servers but missed the problematic integration server somehow.

Hope this helps!

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

Monday, October 22, 2007 12:12 PM by ojaytee

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 Extensions\v1.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.

Thanks,

John

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

Monday, October 22, 2007 12:31 PM by Delay

John,

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.

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

Thursday, October 25, 2007 4:06 AM by andrea81

Hi,

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,

Andrea

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

Thursday, October 25, 2007 11:14 AM by Delay

Andrea,

I believe that the official ASP.NET AJAX 2.0 patch is detailed in the blog I link to in my original post: http://weblogs.asp.net/bleroy/archive/2007/01/31/how-to-work-around-the-quot-access-denied-quot-cross-domain-frame-issue-in-asp-net-ajax-1-0.aspx.

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

Friday, October 26, 2007 4:57 AM by andrea81

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.

Andrea

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

Friday, October 26, 2007 12:47 PM by Delay

Andrea,

The latest ASP.NET AJAX release was created in mid-January based on the dates in my C:\Program Files\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.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.

# I'm getting the access denied error in an iframe and have read stuff and i still can't get it to work! PLEASE HELP ME

Tuesday, November 06, 2007 1:45 PM by ASP.NET AJAX Toolkit Forum Posts

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

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

Saturday, March 15, 2008 9:23 AM by kfsone

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.

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

Monday, March 17, 2008 1:43 AM by Delay

kfsone,

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 http://forums.asp.net/1007.aspx, the people there can probably give you a lot of great feedback!

# Cross domain calls by means of iframe – IE Browser restrictions and solutions

Saturday, April 05, 2008 7:29 PM by iulia

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

# Got a question? Get an answer here

Thursday, April 17, 2008 8:43 PM by ASP.NET Debugging

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

# Ajax y el "Access Denied" cross-domain con un IFrame

Friday, August 01, 2008 5:41 AM by Thempra.NET

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

# Ajax y el "Access Denied" cross-domain con un IFrame

Friday, August 01, 2008 5:41 AM by .

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

Anonymous comments are disabled
 
Page view tracker