[omniORB] Single Login to server program

Duncan Grisby duncan at grisby.org
Mon Aug 2 13:59:39 BST 2010


On Sat, 2010-07-31 at 17:54 +0300, Muro, Sam wrote:

> I am trying to implement a corba program (client) to retrieve customer
> information from the server. Since the server allow to login once and
> perform your operations until the lifetime experies, i want the client to
> use already login connection to perform the retrieve function without
> login in to the server for every request.

OK...

> Suppose retrieve has three functions, logon(), perform() and logoff()
> Pseudo code;
> 1. User runs a client application
> 	./retrieve <corbaloc URI> customerID
> 2. if the client program has already login, donot login, go to 4
> 3. Client program login to the server program
> 4. client program invoke perform(customerID) to retrieve customer information
> 5. Client program submit customer information to the calling program, in
> this case, stdio
> 6. Unless specified, do not logoff

That makes it look like the client program needs to persist the login
information between separate runs. Does it?

[...]
> //I JUST WANT TO PERFORM THIS FUNCTION IFF IT HASNT BEEN INVOKED BEFORE,
> ELSE SKIP THIS METHOD
>   e->Login(username,password,seckey); //NEW seckey WILL BE RETURNED

You are doing the right kind of thing here. You are returning a
"security key" from the server, that the client uses in subsequent
calls. So, to implement what you are talking about, you simply need to
remember that key somehow. How you do it depends on what is appropriate
for your application.

I don't really understand what your question is. You are implementing
your login mechanism purely in your client and server code, so the fact
that you are using CORBA isn't particularly relevant. You just need to
manage the lifetime of your security keys in a way that is appropriate
for you.

As Bruce suggests, it would be possible to do some or all of this behind
the scenes in the CORBA layer with an implementation of the CORBA
security service, but there is not an implementation of that for
omniORB, and anyway, it is over-complicated for your needs as you have
outlined them.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --





More information about the omniORB-list mailing list