[muscle] Re: Authenticated access / private data

  • From: Marius Kjeldahl <marius@xxxxxxxxxxxx>
  • To: muscle@xxxxxxxxxxxxx
  • Date: Thu, 27 Nov 2003 16:49:14 +0100

Seems the list software is mistaking my reply to my own posting as list admin 
commands. Trying again:

When I look at this again, I'm thinking maybe I'm trying to do too much within 
the MUSCLE framework. 

An alternative strategy would be to just use MUSCLE for message stuff and 
shared state stuff (which probably works excellent with the subscribe 
functionality and similar) and let my relational database keep the actual 
game state instead.

That is not to say you are not allowed to suggest a better strategy.

Marius K.

On Thursday 27 November 2003 16:37, you wrote:
> 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: