When we implemented COM objects, or when the ActiveX control is called in the browser, there will be a warning box, prompting the unsafe control is running. This is because the browser security policy is limited, the browser thinks only "safe objects" can be executed.
The so-called security object refers to those objects that do not access local resources, for example, will not read the registry, will not write files, etc. An object that meets the condition tells the browser by supporting the IOBJECTSAFETY interface, it is legal.
Let's take a brief introduction how to implement support for the IObjectsafety interface in C #.
Think
C
/ C D program can find IObjectsafety definitions directly in SDK, so it is easy to support. C # is more troublesome, because we have no way to get the definition of IObjectsafety, but there is no problem, we can redefine the interface in the C # project according to the definition of IOBJECTSAFETY in the SDK.
If you understand the COM mechanism, you will know that the definition of the excuse is in the type library, regardless of implementation. It is judged that the uniqueness of an interface is the UUID specified when the interface is defined. In addition, it is necessary to ensure that the parameters and return values in the interface in the interface must be consistent with the original definition.
Our approach is to find objsafe.idl, then copy the UUID, use this UUID to set an interface IObjectsafety in C #, and the two functions are decremented; after the definition is complete, let the components that need to check the security interface inherit the interface. Inside the component, the two functions of IObjectsafety are implemented, and the appropriate return is made as required, then the COM object packaged with this component is considered safe in IE.
First try
According to the above ideas, we start trying
Interface definition in IDL
[Object, uuid (CB5BDC81-93C1-11cf-8F20-00805F2CD064), pointer_default (unique)] interface IObjectSafety: IUnknown {HRESULT GetInterfaceSafetyOptions ([in] REFIID riid, // Interface that we want options for [out] DWORD * pdwSupportedOptions, // Options meaningful on this interface [out] DWORD * PDWENABLEDOPTIONS); // Current Option VALUES ON THIS INTERFACE
HRESULT SETINTERFACESAFETYOPTIONS ([in] refiid riid, // interface to set options for [in] dword dwoptionSetmask, // Options to change [in] DWORD DWENABLEDOPTIONS; // new option values}
IObjectsafety interface definition
Because there is a pointer in the interface, INT32 is used directly, and Unsafe Code is used.
[Guid ( "CB5BDC81-93C1-11cf-8F20-00805F2CD064")] public interface IObjectSafety {// methods unsafe void GetInterfacceSafyOptions (System.Int32 riid, System.Int32 * pdwSupportedOptions, System.Int32 * pdwEnabledOptions); void SetInterfaceSafetyOptions (System. INT32 RIID, System.Int32 DwoptionssetMask, System.InT32 DwenableDOptions;} Inherited Public Class MyControl: System.Windows.Forms.userControl, IObjectsafety
achieve
//Mplement functions of iobjectsafety public unsafe void getInterfaccesafyOptions (System.Int32 RIID, System.int32 * pdwsupportedOptions, System.int32 * pdwenabledoptions) {
...} public void setInterfacesafetyOptions (System.Int32 riid, system.int32 dwoptionssetmask, system.int32 dwenabledoptions) {
...}
All normal compilation passes, but through the IE call test page, when the page is loaded, a shutdown application system is abnormal, and check the content Error Report is an illegal memory address access. Silent ...
Second try
Since it is an illegal memory address access, natural association is a problem that interface definitions, because there is a unsafe code, and the book discovery does not need to use unsafe code so exaggerated and can be resolved by Out this parameter modifier.
Modify definition and implementation
IObjectsafety interface definition
[Guid ( "CB5BDC81-93C1-11cf-8F20-00805F2CD064")] public interface IObjectSafety {// methods void GetInterfacceSafyOptions (System.Int32 riid, out System.Int32 pdwSupportedOptions, out System.Int32 pdwEnabledOptions); void SetInterfaceSafetyOptions (System.Int32 RIID, System.Int32 dwoptionssetmask, System.Int32 DwenableDOptions;
achieve
// Implement functions of iObjectsafety public unsafe void getInterfaccesafyOptions (System.Int32 riid, out system.int32 pdwsupportedoptions, out system.int32 pdwenabledoption) {
...} public void setInterfacesafetyOptions (System.Int32 riid, system.int32 dwoptionssetmask, system.int32 dwenabledoptions) {
...}
Compile pass, good; IE calls the test page, the same error! Depressed, no fight, go home. Third try
Sleeping, full of food, continue thinking.
I compare the type library generated by the compiler and found some strange phenomena. IObjectsafety in the type library is actually defined two Interface IOBJECTSAFETY: IUNKNOWN, and Dispinterface IOBJECTSAFE: IDISPATCH. The bias MyControl is inherited from DISPINTERFACE IOBJECTSAFETY. This will be in this way with the correct IObjectsafety interface description, the problem should be here.
MSDN, check the document. There are a lot of properties that describe the interface under System.Runtime.InteropService, which can be found in the problem. There is an attribute interfaceTribute, which means that the defined interface is inherited from IUNKNOWN or iDispatch, default is DUAL, so it is two.
Defined again as follows:
[Guid ( "CB5BDC81-93C1-11CF-8F20-00805F2CD064"), InterfaceType (ComInterfaceType.InterfaceIsIUnknown)] public interface IObjectSafety {// methods void GetInterfacceSafyOptions (System.Int32 riid, out System.Int32 pdwSupportedOptions, out System.Int32 pdwEnabledOptions) Void setInterfacesafetyOptions (System.Int32 riid, system.int32 dwoptionssetmask, system.int32 dwenabledoption;} The rest of the code constant, recompile, pass; check the export type library, there is a lot of garbage; call the test page, correct. Excited ...
How to let IE think your object security
Implement this interface, the rest is very simple. As mentioned earlier If you need to ensure that your code doesn't have access to the system locally, follow the documentation requirements, when the object is called in different interfaces, do different feedback. Specific implementation can be found in the MSDN's SAMPLE.
Of course, we can write an object to read and write the local file, but support the IObjectsafety interface, and always declare that you are legal, this to deceive the browser, then the code is very simple, as follows:
// implement functions of IObjectSafety public void GetInterfacceSafyOptions (System.Int32 riid, out System.Int32 pdwSupportedOptions, out System.Int32 pdwEnabledOptions) {pdwSupportedOptions = CLsObjectSafety.INTERFACESAFE_FOR_UNTRUSTED_CALLER; pdwEnabledOptions = CLsObjectSafety.INTERFACESAFE_FOR_UNTRUSTED_DATA;} public void SetInterfaceSafetyOptions (System.Int32 riid, System.int32 dwoptionssetmask, system.int32 dwenabledoptions) {} will not have annoying dialog boxes if you don't have hate.
If your component is installed on the client, then all the work has been completed; so I want to download the release through CodeBase, you still need to engage a digital signature, no one is discussed in this article, Just here, end.
Reference documentation
1, HOWTO: IMPLEMENT IOBJECTSAFETY IN VISUAL Basic Controls
(
Http://support.microsoft.com/default.aspx?scid=kb;n-us;q182598)
2, Exposing .NET Framework Components to COM
(http://msdn.microsoft.com/library/en-us/cpguide/html/cpconeXposingnetFrameworkComponentStocom.asp)
3, System.Runtime.InteropServices (http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemRuntimeInterOpServices.asp)
