[muscle] Authenticated access / private data
- From: Marius Kjeldahl <marius@xxxxxxxxxxxx>
- To: muscle@xxxxxxxxxxxxx
- Date: Thu, 27 Nov 2003 16:37:23 +0100
I am writing multiplayer card games which may very well use the MUSCLE toolkit
for communication and server state data. As with most multiplayer games, the
server needs to handle user authentication and hold private state information
on the server side (assuming any client can be hacked).
MUSCLE's elegant design makes most of this very easy, but I would like advice
from somebody with more MUSCLE experience than I have on the best strategies
for doing user authentication and holding private state information on the
server side.
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
safe, and best case "security by obscurity".
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.
When explaining this, I get the feeling that the authentication part and
holding authentication tokens is trivial _if_ I am able to solve the other
challenge; controlling access to parts of a MUSCLE database based on some
authentication token which can be stored below the IP-address/session tree.
Any advice would be appreciated.
Regards,
Marius Kjeldahl
Other related posts:
