[news.eclipse.technology.ecf] Re: Concerns about this simple chat

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi John,

John F. Patterson wrote:
> I understand that the simple chat outlined here is really more or less a 
> hello world example, but I would like to explore my understanding by 
> rasing some concerns about it.
>
> First, since the ID of the SharedObject is based on a well-known name, 
> i.e., "chat" anyone who has permission to join the server.com container 
> may join the chat.  How do we restrict the chat to a limited audience?  

In general, there will be many ways that containers could authenticate. 
   The purpose of the 2nd param in the joinGroup(ID,Object) method call 
is to allow the passing of arbitary information for authentication (so, 
for example, the Object could be a JAAS LoginContext).

> One approach seems to be to create the chat object with a random name
> and do a sendCreate to those we wish to invite.  Does this sound 
>right?

Even if the random name is truly unguessable, sending a message to an 
invitee in the clear would be insecure.
The intention of the 'sendCreate' message is really to allow the 
creation of a remote replica of a given shared object.  This message 
could be used to just communicate an ID for a new group, but it would 
really just be preferable to use sendMessage(remoteInvitee,newGroupID). 
 Then the receiver could respond to this message by creating a new 
container and joining that container.  If the container requires 
authentication and the invitee has it it can provide it, if it doesn't 
have it then the invite was not appropriate anyway.

<stuff deleted>

> Second, there does not appear to be any way to know who has joined the 
> chat.  

No.  config.getContext().getGroupMemberIDs() provides the current group 
membership.  Also:

config.getContext().getSharedObjectManager().getSharedObjectIDs()

provides information about the current shared objects.

<stuff deleted>

> Third, since the name associated with a chat entry is completely under 
> the control of the user, anyone could contribute to the chat without 
> ever revealing the login name associated with their access to 
> server.com.  

This is just the way I chose to implement the nickname functionality in 
this example.  It would probably be more common for each user to have 
their own 'presence' object...where the ID for the object really is a 
full user identity.  In that case, however, the chat would receive 
messages from the presence object and use the sender object ID to be
 sure that it's who it says it is.

Do the messages arrive tagged by the authenticated name of
> the sender?  

Yes.  In the events that are ISharedObjectEvent implementers have a 
method ISharedObjectEvent.getSenderSharedObjectID().  Both messages from 
remote replicas (ISharedObjectMessageEvent), and from local 'other' 
shared objects (ISharedObjectEvent) have access to the 'sender'

> If so, why wouldn't we use that name in the chat transcript?

You could.  And for some chats you surely would.  Other chats it would 
not be desired or necessary...it would depend upon the requirements on 
the chat.

Scott

> jfp
> Scott Lewis wrote:
>
> > Hi John,
> >
> > John F. Patterson wrote:
> >
> > > OK, I see where I messed up.  I mistook the names passed in to the 
> > > Chat object as the idenitifiers, but they clearly are not the IDs.  
> > > They are merely nicknames that are bundled into the sent object 
> > > (actually Object array).  The ID for the objects is "chat" on both 
> > > sides.  Presumably, everyone with access to the container who also 
> > > creates the "chat" object. may use the sendObjectToRemote method and 
> > > the chat will go to System.out.  Is this right?
> >
> >
> >
> > Yes indeed!
> >
> > Scott