[muscle] Re: Authenticated access / private data
- From: Jeremy Friesner <jeremyfriesner@xxxxxxxxxxxxx>
- To: muscle@xxxxxxxxxxxxx
- Date: Thu, 27 Nov 2003 08:31:36 -0800 (GMT-08:00)
Hi Marius,
>For user authentication, I typically want the server to authenticate the
>client using a challenge/response scheme (think md5 or traditional
>username/password authentication) and setting some flag in the server-side
>state data that says "authenticated". The natural place to put it would be
>below the session tree in a StorageReflectSession (to allow people playing
>multiple sessions simultaneously), but since the clients have full read and
>write access below their respective trees, this could hardly be considered
s>afe, and best case "security by obscurity".
This is easy enough to do. Make your own subclass of the StorageReflectSession
class, and your own subclass of ReflectSessionFactory that you can attach
to your server to tell it to use your subclass (as described in the "How to
make a Custom Server" document on the MUSCLE web site). Once that is
set up, you can override the StorageReflectSession::MessageReceivedFromGateway()
method in your StorageReflectSession subclass, so that it does the
authentication,
and only passes the method call up to the superclass if the "authenticated"
flag is set.
>Holding server state data is similar. In any card game, and lots of other
>games, some information is "public" (table cards, game board) and other
>information is "private" (private cards, event cards etc.). My software will
>allow disconnected clients to reconnect and "resume" where they left off,
>which means server side state data (except possibly authentication data as
>explained earlier) will be stored _outside_ the IP-address/session trees for
>each client (since these trees are lost when clients disconnect). So I am
>probably going to be creating a similar tree to the IP address/session trees
>which does not go away when the client disconnects, so that on a client
>reconnect event the server will be able to figure out where the client left
>off. Each client will get full access to its state data after successful
>authentication.
I've found that the best way to do this is to create a seperate "game state"
session object (i.e. another subclass of StorageReflectSession, one object
of which is instantiated and added to the server, but that has no IOGateway
object attached to it, and thus no TCP connection to any client associated with
it).
This state-session gets added to the server as part of the server's setup, and
stays attached to the server indefinitely. This session can then handle all
the
stuff you describe above, publish nodes, handle any global logic, etc. See
the document on how to create a custom server, and the FoxRabbitCarrot
article/example for details.
Jeremy
Other related posts:
