Restricting functionality on objects: "remote access proxy" (pattern)

Hello!

Before anyone complains, this is basically a multipost from the
mainstream Java NG's. I couldn't get any/the answers I need, so I must
go to (what is for me) the "OO-design experts group". ;-)

I have a (Java) interface "Chat":

public interface Chat
{
public String getName();
public void setName(String strName); //basically not executable by
everyone

public User getOwner();
public void setOwner(User usrOwner); //basically not executable
by everyone

public List<User> getUserList();

//... which methods?
//join(User usr)
//sendMessage(User usr, Message msg)
//kick(User usr, User usrKicker)
//ban(User usr, usrBanner)
//unban(User usr, usrUnbanner)
//leave(User usr)
//...

}

How do you restrict access for a real chat room on the network by
using the current (or another user's) level/permissions (there are
admins, mods, owners, ops, normal users)?

1. The easiest way is probably not to expose functionality via the
GUI, so users with admin level will see a popup with more entries than
a regular chatter. However this is no real security concept. Accessing
the model objects can still produce an unwanted command (e.g. by some
artificial instance not having a GUI at all).

2. The list of commands generated via some CommandFactory (the objects
that would do something when a button gets pressed) is limited by the
user's (or some other) level. A normal user can't instantiate a
"BanCommand" for example. The command objects act as messenger
objects, but nevertheless those objects would still call the public
unfiltered methods on that interface.

3. Somehow provide different implementations of that interface by
subclassing (or else) and throwing some exception for those operations/
method calls that are not allowed with the current user's level. A
normal user calling myChat.ban(otherUser) would get such an exception.
Disadvantage of subclassing here would be, that I'd need one subclass
per user level (admin, moderator, owner, operator, normal). In case
the user's level gets upgraded, the instance/s of such chats would
have to be replaced. Looks like bad design to me.

Instead of subclassing one could also implement this via several
Strategies, one per method. I believe the "Bridge" pattern could be
applied as well, for dynamic method implementations.

In any way, I started creating a concrete subclass of a Chat interface
called "ChatProxy" which is supposed to
handle the communication with the actual chat server (no
implementation yet). Maybe that is supposed to be the class where the
restrictions belong. Such a proxy might act as an "access proxy" but
also as a "remote proxy".

I could need some more input on this matter designwise. Currently I
have the above Chat interface and two subclasses:

public abstract class ChatImpl implements Chat (needed at all???
what does it implement anyway??)
....

and

public class ChatProxy implements Chat
{
private final ChatImpl ci; //references above class

//^^dump the reference and concrete class at all, connecting to
the server directly?

//...implement the methods here, depending on the current user's
level

}

This is the naive approach of the GoF Proxy pattern that I started
with. I'm not quite sure if I need the ChatImpl class at all or
whether the proxy will connect to the server directly. (?)

Be aware that it is a requirement to upgrade user levels on the fly,
so having a ProxyFactory with different Chat(Proxy) implementations
per user level (admin, mod, owner, op, normal) might not be the right
thing.

I'm really out of ideas what could be the right way to do it, though
restricting functionality on (dynamic) user levels seems quite common
to me. This is why I hope to get some more insight from you, even if
you only left some comments "you're basically on the right way", "it's
probably better to do this", "forget that"...

Any help is greatly appreciated!

Karsten

PS: Which instance is supposed to handle the authentication stuff
anyway? The Proxy itself? Another "connection" object?

.

Quantcast