[omniORB] Module without interface definition

Discussion:

Muro, Sam

2010-07-14 03:30:47 UTC

Hello there.
I have the following idl (Data.idl) which consist of two modules, but only
one of them has the Interface defined.

***
//File BasePrompts.idl
//
#ifndef __BASEPROMPTS__
#define __BASEPROMPTS__
module Base
{
struct Selector
{
string subjecName; // Attribute Name
string subjectCode; // Attribute Value
};

typedef sequence<Selector> BaseList;
};
#endif

//FILE Data.idl
//
#include <BasePrompts.idl>
module Camp
{
// Result Feeback
enum feedback
{
ok,
rejected
};

Interface Core
{
feedback eScores(
in string<255> username,
in string<32> passwd,
in string<32> scores,
inout Base::BaseList baseList); // Function Attributes/Result Attributes
};
};
***

I would like to invoke eScores() from the client application using the
following snippets;

static void invokeOperation(Camp_ptr e)
{
CORBA::String_var username = (const char*) "Mimi";
CORBA::String_var password = (const char*) "ohh!";
CORBA::String_var scores = (const char*) "B+";

****how do I define one for sequence Baselist), say baselist

{ReturnType} myElements = e-> eScores(username, password, scores,
baselist) //I need help here
.
.
.
}

Please assist for those who knows the workaround

Regards
Sam

Thomas Lockhart

2010-07-14 03:59:33 UTC

Permalink

An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100713/8d11af35/attachment.htm

Muro, Sam

2010-07-14 15:18:20 UTC

Permalink

Thanks Tom
This one works perfect. I was doing Base.Baselist_var which gave me the error

Thank you very much

Regards
Sam

Post by Muro, Sam
****how do I define one for sequence Baselist), say baselist

Base::BaseList baselist;
baselist.length(1);
baselist[0].subjectName = CORBA::string_dup("name");
baselist[0].subjectCode = CORBA::string_dup("one");
hth
- Tom

Muro, Sam

2010-07-31 20:54:27 UTC

Permalink

Hi
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.

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

Here is the code snippets;

static void login(Base::Customer_ptr e) {

CORBA::String_var username = (const char*) "mimi";
CORBA::String_var password = (const char*) "ahh!!";
CORBA::String_var seckey= (const char*) "";
Base::BaseList BaseLists;

BaseList.length(2);
BaseList[0].bName = CORBA::string_dup("CATEGORY");
BaseList[0].bValue = CORBA::string_dup("VIP");

BaseList[1].bName = CORBA::string_dup("CATEGORY");
BaseList[1].bValue = CORBA::string_dup("VIP");

//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

Base::BaseResult result;
result= e-> Perform(seckey, BaseList);

cerr << "***********************************" <<endl
<< "**** TASK RESULT *****" <<endl
<< "**** \t"<< taskresult << " *****" <<endl
<< "***********************************" <<endl;

//PERFORM THIS FUCTION ONLY IF NECESSARY, MAY CHECK argc[] for specified
option
e-> logoff();

}

I also want to make this be multithreads.
Any input is highly appreciated

Sam

Bruce Visscher

2010-07-31 22:59:32 UTC

Permalink

I think to really do this properly, you need CORBA security.? What is
the status of this in omniORB?

Post by Muro, Sam
Hi
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.
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
Here is the code snippets;
static void login(Base::Customer_ptr e) {
?CORBA::String_var username = (const char*) "mimi";
?CORBA::String_var password = (const char*) "ahh!!";
?CORBA::String_var seckey= (const char*) "";
?Base::BaseList ?BaseLists;
?BaseList.length(2);
?BaseList[0].bName = ?CORBA::string_dup("CATEGORY");
?BaseList[0].bValue = CORBA::string_dup("VIP");
?BaseList[1].bName = ?CORBA::string_dup("CATEGORY");
?BaseList[1].bValue = CORBA::string_dup("VIP");
//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
?Base::BaseResult result;
?result= ?e-> Perform(seckey, BaseList);
?cerr ?<< "***********************************" <<endl
? ? ? ?<< "**** ? ? ? ? TASK RESULT ? ? ?*****" <<endl
? ? ? ?<< "**** ? ? \t"<< taskresult << " ?*****" <<endl
? ? ? ?<< "***********************************" <<endl;
?//PERFORM THIS FUCTION ONLY IF NECESSARY, MAY CHECK argc[] for specified
option
?e-> logoff();
}
I also want to make this be multithreads.
Any input is highly appreciated
Sam
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

Muro, Sam

2010-08-01 06:01:00 UTC

Permalink

Hello Bruce
What do you mean by the status?

I have done all coding except the login scenario mentioned and multithread
in case is the status you are referring to.

Sam

Post by Bruce Visscher
I think to really do this properly, you need CORBA security.? What is
the status of this in omniORB?

Muro, Sam

2010-08-01 06:01:23 UTC

Permalink

Hello Bruce
What do you mean by the status?

I have done all coding except the login scenario mentioned and multithread
in case is the status you are referring to.

Sam

Post by Bruce Visscher
I think to really do this properly, you need CORBA security.? What is
the status of this in omniORB?

Muro, Sam

2010-08-02 09:44:36 UTC

Permalink

Can someone advice the way forward.

Post by Muro, Sam
Hello Bruce
What do you mean by the status?
I have done all coding except the login scenario mentioned and multithread
in case is the status you are referring to.
Sam

Post by Bruce Visscher
I think to really do this properly, you need CORBA security.? What is
the status of this in omniORB?

Thomas Lockhart

2010-08-02 23:33:20 UTC

Permalink

If your login method returns a callback object then you can do
subsequent operations with the client invoking the callback object
directly, bypassing the login operation. I suppose the callback object
could require a key of some sort to avoid unexpected access from
elsewhere. The logout method could destroy the remote object.

I'm not sure that this scheme would win a tradeoff with the other style
you are discussing, but...

hth

- Tom

Muro, Sam

2010-08-03 12:37:18 UTC

Permalink

This is exactly want i want to implement. When the client object is
invoked, It returns a security key which will be needed for any subsequent
operations until its life time expires. I am not very experienced in this
but what i need is ability to remember that key, access it priori to
invoking login() method. For example, one can store the security key into
a file, and access it using md5checksum to guarantee that no one has
changed its content. The question is how to do this

Kindly assist if you can paste some code snippets of what you think will work

Sam

Post by Thomas Lockhart
If your login method returns a callback object then you can do
subsequent operations with the client invoking the callback object
directly, bypassing the login operation. I suppose the callback object
could require a key of some sort to avoid unexpected access from
elsewhere. The logout method could destroy the remote object.
I'm not sure that this scheme would win a tradeoff with the other style
you are discussing, but...
hth
- Tom

Thomas Lockhart

2010-08-04 04:32:44 UTC

Permalink

An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100803/d5cd932e/attachment.htm

Muro, Sam

2010-08-04 13:15:20 UTC

Permalink

Post by Muro, Sam

Post by Muro, Sam
This is exactly want i want to implement. When the client

object is

Post by Muro, Sam
invoked, It returns a security key which will be needed for any
subsequent operations until its life time expires. I am not very
experienced in this but what i need is ability to remember that key,
access it priori to invoking login() method. For example, one can
store the security key into a file, and access it using md5checksum
to guarantee that no one has changed its content. The question is how
to do this
Kindly assist if you can paste some code snippets of what you think will work

interface SecureServer {
void DoSomething(in long key);
void DoSomethingElse(in long key);
oneway void logout(key);
};
interface SecureLogin {
void login(in string user, in string pw, out SecureServer server, out
long key);
};
From the client, you would find your secure login server (possibly using
sl->login(user, pw, ss, key);
ss->DoSomething(key);
ss->DoSomethingElse(key);
ss->logout(key);

This is ok. But now suppose you do not want to logoff so that the next run
make use of the secure key to make a connection to the server, how do we
store this key for future use?

// debug(--retrieve the saved key from--)

if (!key){
s1->login(user, pw, ss, key);

};
try {
ss->DoSomething(key);
ss->DoSomethingElse(key);
ss->logout(key);
}
catch (login_exceptions){
debug(....);
ss->login(user, pw, ss, key)
debug(--save the key for future use--) //HOW
}

Post by Muro, Sam
In the server, the login method would create a temporary server object
implementing the SecureServer interface and return a handle and a key.
Subsequent calls to that new server object (or an object from a pool)
would include that key for validation. The call to logout would destroy
the object or the key and validated connection.
If you have a good book on C++ CORBA ("Advanced CORBA Programming with
C++" by Henning and Vinoski is the best for any language imo) then
looking for examples which return iterators will illustrate these
temporary server-side objects.
My use of the word "secure" is just for illustration; others may point
out possible weaknesses in this approach.
hth
- Tom

Thomas Lockhart

2010-08-04 23:20:45 UTC

Permalink

An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100804/afbdda51/attachment.htm

Duncan Grisby

2010-08-02 17:59:41 UTC

Permalink

Post by Muro, Sam
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...

Post by Muro, Sam
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?

[...]

Post by Muro, Sam
//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 --
-- ***@grisby.org --
-- http://www.grisby.org --

Muro, Sam

2010-08-02 23:20:25 UTC

Permalink

Post by Duncan Grisby

OK...

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

That is correct.

Post by Duncan Grisby
[...]

Post by Muro, Sam
//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

So what you are saying is that this should be a client programing language
issue, in this case C++. Can you tip me the howto. Im now thinking of
writing a keyfile and call to check if the key is still valid.

Post by Duncan Grisby
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.