Re: ActiveX control and Authorization issue
From: Alexander Nickolov (agnickolov_at_mvps.org)
Date: 10/25/04
- Next message: Semut: "Re: CComQIPtr/CComPtr resource leak check"
- Previous message: Robert: "ActiveX control and Authorization issue"
- In reply to: Robert: "ActiveX control and Authorization issue"
- Next in thread: Robert: "Re: ActiveX control and Authorization issue"
- Reply: Robert: "Re: ActiveX control and Authorization issue"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 25 Oct 2004 15:30:02 -0700
When writing a control you can't change the process-wide
security settings the way you do in standalone apps. Your call
to CoInitializeSecurity simply fails with RPC_E_TOO_LATE.
-- ===================================== Alexander Nickolov Microsoft MVP [VC], MCSD email: agnickolov@mvps.org MVP VC FAQ: http://www.mvps.org/vcfaq ===================================== "Robert" <Robert@discussions.microsoft.com> wrote in message news:271F7D1D-3BE2-428D-8BC2-D7F81815E349@microsoft.com... > Hello, > > I am running a DCOM server on Win XP Pro, developed with VC++ 6, MFC. The > machine on which my server runs has machine-wide DCOM properties settings > set > thusly: > > Default Authentication Level: Connect > Default Impersonation Level: Identify > > Of course, when my server registers itself, I configure the specific > server > to use Authentication Level: None, and Identity is Interactive user > (through > DCOMCNFG). > > Internally, when my server runs, I call: > > hr = CoInitializeSecurity(NULL,-1,NULL,NULL, > RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_IMPERSONATE, > NULL, EOAC_NONE, NULL); > > My understanding is this call will take precedence over registry settings > anyway. > I have developed DCOM clients in MFC that connect successfully to this > server without the user having to configure anything in DCOMCNFG or > anything > like that. My typical client setup makes the SAME CALL to > CoInitializeSecurity(), then tries to call CoGetClassObject(). > > From my client, I have COAUTHINFO.AuthIdentity set to NULL, my auth is > > NONE and I don't need to impersonate or anything (in my call to > CoGetClassObject()). This has always worked until I wrote an ActiveX > client > to work the same as a regular MFC DCOM client app. If my machine wide > setting > on this client machine is set to (these are DCOM defaults when OS is > installed) > > Default Authentication Level: Connect > Default Impersonation Level: Identify > > (same as server and as previous working, non ActiveX clients), my ActiveX > control fails when calling my IDispatch::Invoke() (with unknown error > code) > -> The call does arrive at my server's QueryInterface(). If I go ahead and > change the Machine wide Default Auth Level to "NONE", everything works > with > my ActiveX control. My problem is that I don't want users downloading my > ActiveX (via Internet Explorer as the container), to have to do any extra > steps (in DCOMCNFG) to run my ActiveX, aside from just opening up their > browser and surfing to the desired page. Do I need to change to internal > "Connect" authorization and provide an internal account valid on the > server > in order to get my ActiveX to run seamlessly? > > Any help here would be greatly appreciated...I have tested so many > different > scenarios and am still having trouble.... > > Thank you, > > Robert
- Next message: Semut: "Re: CComQIPtr/CComPtr resource leak check"
- Previous message: Robert: "ActiveX control and Authorization issue"
- In reply to: Robert: "ActiveX control and Authorization issue"
- Next in thread: Robert: "Re: ActiveX control and Authorization issue"
- Reply: Robert: "Re: ActiveX control and Authorization issue"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|