Article ID: 216434
Article Last Modified on 3/22/2007
APPLIES TO
- Microsoft Internet Explorer 4.0 128-Bit Edition
- Microsoft Internet Explorer 4.01 Service Pack 2
- Microsoft Internet Explorer 4.01 Service Pack 1
- Microsoft Internet Explorer 4.01 Service Pack 2
- Microsoft Internet Explorer 5.0
- Microsoft Internet Explorer 5.01
- Microsoft Internet Explorer (Programming) 5.01 SP1
- Microsoft Internet Explorer 5.5
This article was previously published under Q216434
SUMMARY
When you use ActiveX controls on a Web page, depending on your security level, you may receive the following warning message in Internet Explorer:
This article explains how Internet Explorer determines if an ActiveX control is considered safe for scripting and initialization.
MORE INFORMATION
There are two ways to mark a control as safe for scripting and initialization:
- Implement the IObjectSafety interface.
- Provide the following registry keys for the control's CLSID under the Implemented Categories section:
- The following key marks the control safe for scripting:
- The following key marks the control safe for scripting:
{7DD95801-9882-11CF-9FA9-00AA006C42C4}
- The following key marks the control safe for initialization from persistent data:
- The following key marks the control safe for initialization from persistent data:
{7DD95802-9882-11CF-9FA9-00AA006C42C4}
Microsoft recommends that you implement IObjectSafety to mark a control as safe or unsafe. This prevents other users from repackaging your control and marking it as safe when it is not.
The IObjectSafety interface allows a container to retrieve the control's initialization and scripting capabilities through its SetInterfaceSafetyOptions method. First, Internet Explorer checks to see if a control implements the IObjectSafety interface. If it does, Internet Explorer calls SetInterfaceSafetyOptions for the IPersist interfaces to check if the object is safe for initialization. When a control is first scripted, Internet Explorer first calls SetInterfaceSafetyOptions on the IDispatchEx interface of the control. If that fails, it calls SetInterfaceSafetyOptions on the IDispatch interface.
If the control returns unsafe for any of the interfaces, Internet Explorer warns the user according to the user's security settings for that zone (Internet, Local Intranet, and so forth).
If the control does not implement the IObjectSafety interface, Internet Explorer looks under the Implemented Categories section of the control for the keys mentioned above. If these keys are not present, Internet Explorer warns the user according to the security settings.
NOTE: The implementation of the IObjectSafety interface always takes precedence. If a control implements the IObjectSafety interface and returns unsafe for the IDispatch or IPersist interfaces, the registry keys are ignored even if they are present in the Implemented Categories section.
In some cases, a control may be "blindly" aggregated, and the aggregator may pass the QueryInterface function calls directly to the aggregated control. If the aggregated control implements IObjectSafety and marks itself unsafe, any registry entries in the aggregator are ignored. In this scenario, you can implement IObjectSafety explicitly on the aggregator and expose only the safe methods of the aggregated control.
REFERENCES
For more information, see the Component Development section on the Microsoft Developer Network (MSDN) Web Workshop site:
For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
161873 HOWTO: Mark MFC controls safe for scripting/initialization
168371 HOWTO: IObjectSafety marks ATL controls safe for initializing
182598 HOWTO: Implement IObjectSafety in Visual Basic Controls
(c) Microsoft Corporation 1999, All Rights Reserved. Contributions by Kusuma Vellanki, Microsoft Corporation.
Keywords: kbinfo kbdownload kbsecurity kbctrlcreate kbfaq kbcode KB216434
