Troubleshooting: Embedded Browser Error: An error has occurred in the script on this page

Version Affected: All
 
 

Overview

When a user authenticates from inside an embedded browser control — for example, Box Sync, Palo Alto GlobalProtect, Outlook Mobile, or another application's built-in browser — the same underlying issue can surface a few different ways, depending on the embedded browser and the workflow it's used for:

• A script error dialog reading "An error has occurred in the script on this page: 'WebForm_DoPostBackWithOptions' is undefined".
• The same kind of script error citing "'__doPostBack' is undefined" instead, often appearing when navigating back to a previous page during login.
• A .NET server error reading "Object reference not set to an instance of an object" (a System.NullReferenceException), particularly when the user selects Push Notification/Push-to-Accept as their MFA method.
• On Outlook Mobile specifically, a generic "Authentication Error", "An Error in Authentication has Occurred", or the same "Object reference not set to an instance of an object" message, after tapping Accept for a Push Notification.

All of these are produced by the same underlying cause, described below.

 

Cause

Internet Information Services (IIS) determines which browser features to serve based on the requesting browser's user agent string. Some embedded browser controls use a user agent that ASP.NET doesn't recognize, so IIS can't confirm the browser supports the EcmaScript version required for a postback. When a browser isn't recognized, ASP.NET "down-levels" the functionality it serves to it by default — disabling script-dependent features such as WebForm_DoPostBackWithOptions — which produces this error.

 

Resolution

Register the embedded browser's user agent in a browser definition file so IIS recognizes it as supporting the required EcmaScript version:

1. Create a folder named App_Browsers inside the affected realm's directory: D:\SecureAuth\SecureAuth<realm>\App_Browsers.
2. Inside that folder, create a new file with a .browser extension. Any filename works, as long as the extension is .browser.
3. Add a <browsers> definition matching the embedded browser's user agent, and grant it the required ecmascriptversion capability. For Box Sync's embedded browser:

<browsers>
    <browser id="BoxSync" parentID="Default">
        <identification>
            <userAgent match="Box Sync" />
        </identification>
        <capabilities>
            <capability name="ecmascriptversion" value="3.0" />
        </capabilities>
    </browser>
</browsers>

4. For Palo Alto GlobalProtect's embedded browser, use the same pattern with its own user agent:

<browsers>
    <browser id="GlobalProtect" parentID="Default">
        <identification>
            <userAgent match="GlobalProtect" />
        </identification>
        <capabilities>
            <capability name="ecmascriptversion" value="3.0" />
        </capabilities>
    </browser>
</browsers>

5. For Outlook Mobile's embedded browser, use the same pattern again — only the file name and user agent change:

<browsers>
    <browser id="Outlook" parentID="Default">
        <identification>
            <userAgent match="Outlook" />
        </identification>
        <capabilities>
            <capability name="ecmascriptversion" value="3.0" />
        </capabilities>
    </browser>
</browsers>

6. This same pattern resolves any of the symptom variants listed in the Overview above, from any other embedded browser that supports EcmaScript v3 or higher — replace Application Name below with an identifying string from that application's own user agent:

<browsers>
    <browser id="Application Name" parentID="Default">
        <identification>
            <userAgent match="Application Name" />
        </identification>
        <capabilities>
            <capability name="ecmascriptversion" value="3.0" />
        </capabilities>
    </browser>
</browsers>

Special Considerations

The embedded browser may need other <capabilities> defined beyond ecmascriptversion, depending on what functionality the application actually requires — some additional testing may be needed to identify them. See Microsoft's browserCaps element reference for the full list of capabilities that can be defined in a .browser file.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.