Interface-based security?
- From: "jesse" <jessegarbage@xxxxxxxxx>
- Date: 23 Aug 2006 08:34:42 -0700
I want to create a DCOM server that allows some users to call certain
methods, and other users to call other methods. I will settle for a
compromise or workaround, but I'd like to know what others would do
here. Here's the situation:
I have a COM object hosted in a service. It serves as a database--the
client applications need to access about 40 GB of data at random, speed
is of the essence. The service runs on a box that has over 100 GB of
memory, so this works. The com object uses the
DECLARE_CLASSFACTORY_SINGLETON() macro, so all clients are talking to
the same instance. One client modifies/writes data, other clients only
read data. The object serves the client applications perfectly. Since
this all runs on a secure machine, remote access is disabled in DCOM
config, and that's that.
This has all been working perfectly until now. Now I need other
machines to be able to read data from this server. Ideally, I'd like
to break off methods like WriteData() into a separate interface, called
IDataWriter and have that interface not accessible from the remote
clients.
I've considered overriding QueryInterface and return E_FAIL if the
client is remote, but I don't know how to determine if it's remote or
local. Also, I'm not sure if this is a safe approach.
Any suggestions?
TIA,
Jesse
.
- Follow-Ups:
- Re: Interface-based security?
- From: Alexander Nickolov
- Re: Interface-based security?
- From: Brian Muth
- Re: Interface-based security?
- Prev by Date: Re: Using the VB/VBA Collection class in C++ code
- Next by Date: Re: Interface-based security?
- Previous by thread: is there any problem the way i use ccomsafearray?
- Next by thread: Re: Interface-based security?
- Index(es):
Relevant Pages
|
Loading