How to solve the JavaScript "access rejection" problem in the case of ASP. NET Ajax 1.0 cross-domain framework [translation]

Recently, I used the ASP. NET ajax1.0 framework to throw an "Access dennied" exception under different domain names. Search for this article on Google
How to work around the Access Denied cross-domain frame issue in ASP. NET Ajax 1.0

It solved my problem and I thought the author had a good analysis. I translated the problem in English and hoped to use it for my friends who studied ASP. NET Ajax.

The translation is as follows:

How to solve the JavaScript "access denial" problem in the case of ASP. NET Ajax 1.0 cross-domain framework

Some users may have used the Asp.net Ajax program in a frame or IFRAME that is inconsistent with the top-level window domain name. When you browse these web pages in the IE browser, ie will throw an "Access Denied" (Access denied) exception for any client DOM events (such as mouse clicks) triggered in the framework. The cause of this situation is the SYS. UI. getlocation method in microsoftajax. js. There is a tricky piece of code to get the pixel value of a DOM element relative to the coordinate in the upper left corner of the page. Therefore, the sub-elements in the absolute position under the body use these coordinates to accurately Replace the elements you have measured. This method is used when you drag the mouse to bring up the menu, for example, automatically complete. You can use it to obtain the coordinates of the mouse relative to the trigger mouse event element. Because we cannot dynamically determine the behavior of different browsers Based on the browser's compatibility, the code in SYS. UI. getlocation at one time is a specific rewrite for different browsers. You only need to know that, for example, a browser does not calculate the scroll position of an element. When this element is a direct sub-element of the body and is an absolute position. This is a problem we need to solve. Fortunately, there are two convenient methods for IE to completely bypass some bugs that we cannot effectively solve. Getclientrects: obtains the area where an element occupies all the rectangles of the page. Getboundingclientrect: returns a rectangular area containing the entire element. In our method, we have used the getclientrects method and obtained the first rectangular area. Because we need to unify the behavior between different browsers, even for a packed element span. In this case, the upper left corner of the element is the upper left corner of the first rectangular area that contains the element, different from the global rectangular area that contains the element. For example:

This is our mistake. Unfortunately, it is too late. There is only one difference between getclientrects and getboundingclientrect. The difference is that when getclientrects is used under the frame, the given coordinates include the Offset Value of the frame in the top-level window (offset is often described by the offsetleft offsettop attribute of the element ). However, getboundingclientrect directly returns coordinates that do not include offsets. Both methods must include calculating the height and width of frameborder to be perfect and accurate. To correct getclientrects, we have to pay attention to the coordinates of the frame relative to the top-level window and subtract them. However, this operation is forbidden in a cross-domain framework.

The solution is to use getboundingclientrect instead of getclientrects. Although using encapsulated elements (such as span), this method will bring some inconsistency between different browsers, but it is always much better than a complete failure. The new functions still need to use try/catch to solve the frameboder issue. Therefore, the coordinates may be deviated by two pixels in cross-domain framework, but this is already the best result.

Steps to solve the problem

First, you need to use an external script file to replace the Resource-Based Script compiled in the DLL.You can achieve this by setting scriptpath of scriptmanager. External script packages can be in the Microsoft Ajax Library (http://ajax.asp.net/downloads/library/default.aspx? Tabid = 47 & subtabid = 471). It is based on mspl and you can modify the content of the script file. After Microsoft Ajax library is decompressed, copy the system. Web. Extensions folder to the location specified by scriptpath. If you do not want all scripts to be referenced Based on the path, you can only specify the core script file microsoftajax. js to be referenced through the path. Other script files will continue to use web resources. This makes it easier to use other resource-based libraries, such as toolkit. You can easily add the following scripts to your script Manager:

Of course, do not forget to replace [your script directory] with the corresponding path in your web program. If you use this script reference method, you cannot set scriptpath in script manager. After completing the preceding steps, you can check whether the program can continue to work normally and use network monitoring tools such as fidder to load scripts from the new path.

The second step is to fix the bug in the original script.. We need to fix the debug version (microsoftajax. Debug. JS) and release version of the script.

Find the following code snippet in microsoftajax. Debug. JS:

 

Switch (SYS. browser. Agent ){
Case SYS. browser. internetexplorer:

Replace all codes between "case SYS. browser. Safari:" with the following code. SYS. UI. domelement. getlocation = function (element ){
If (element. Self | element. nodetype = 9) return New SYS. UI. Point (0, 0 );
VaR clientrect = element. getboundingclientrect ();
If (! Clientrect ){
Return new SYS. UI. Point (0, 0 );
}
VaR ownerdocument = element.document.doc umentelement;
VaR offsetx = clientrect. Left-2 + ownerdocument. scrollleft,
Offsety = clientrect. Top-2 + ownerdocument. scrolltop;

Try {
VaR F = element. ownerdocument. parentwindow. frameelement | NULL;
If (f ){
VaR offset = 2-(F. frameborder | 1) * 2;
Offsetx + = offset;
Offsety + = offset;
}
}
Catch (Ex ){
}

Return new SYS. UI. Point (offsetx, offsety );
}
Break;

 

For versions released (microsoftajax. JS), the steps are basically the same, except for files that are a little difficult to operate (it is not easy to select a program that is made into several lines ). Find the code snippet

"Switch (SYS. browser. Agent) {Case SYS. browser. internetexplorer :". Replace all codes between "case SYS. browser. Safari:" with the following code

switch(Sys.Browser.agent){case Sys.Browser.InternetExplorer:Sys.UI.DomElement.getLocation=function(a){if(a.self||a.nodeType===9)return new Sys.UI.Point(0,0);var b=a.getBoundingClientRect();if(!b)return new Sys.UI.Point(0,0);var c=a.document.documentElement,d=b.left-2+c.scrollLeft,e=b.top-2+c.scrollTop;try{var g=a.ownerDocument.parentWindow.frameElement||null;if(g){var f=2-(g.frameBorder||1)*2;d+=f;e+=f}}catch(h){}return new Sys.UI.Point(d,e)};break;

At this time, the website should not throw an exception.

Known consequences of this correction

• The coordinates returned by sys. UI. domelement. getlocation are offset by 2 pixels in different domain name frame scenarios.
• This correction returns the coordinates in the upper-left corner of the element boundary, instead of the upper-left corner of the first rectangle that contains the current element, which is different for the wrap element (SPAN. The returned values are inconsistent in different browsers.

Important Disclaimer

This fix means you have to stop using resource-based scripts, instead of static file versions. I hope this problem will be solved when the next service package is released. Therefore, when system. Web. Extensions releases a new version, you will need to restore the use of resource-based scripts to get fixes or updates to other problems.