[muscle] Re: Authenticated access / private data

  • From: "Mika Lindqvist" <linki@xxxxxxx>
  • To: <muscle@xxxxxxxxxxxxx>
  • Date: Thu, 27 Nov 2003 18:20:03 +0200

> -----Original Message-----
> From: muscle-bounce@xxxxxxxxxxxxx=20
> [mailto:muscle-bounce@xxxxxxxxxxxxx] On Behalf Of Marius Kjeldahl
> Sent: Thursday, November 27, 2003 5:49 PM
> To: muscle@xxxxxxxxxxxxx
> Subject: [muscle] Re: Authenticated access / private data
>=20
>=20
> When I look at this again, I'm thinking maybe I'm trying to=20
> do too much within=20
> the MUSCLE framework.=20

If we push MUSCLE to it's limits one thing we gain is that we know what
might be the next things to add to it's functionality. Now we mostly use =
the
standard MUSCLE suite, but maybe it's time to do generic "add-on" that =
can
store address independent data and actually do something more than just
store information, to actually process the information and control the =
flow.
I think the "dumb" session in current MUSCLE suite is a start, but we =
need
to add more features and logic to it.

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

The only possible way that this has been possible with current =
"standard"
MUSCLE daemon in my own opinion has been separate "daemon bot" =
connection /
program that stores the private information, so *user* clients can't =
fake or
manipulate any sensitive information and/or data.

I have one bot that actually can use external database for =
authentication,
so it can be done even with current MUSCLE daemon as long as the clients
know how to send the "login". It also calculates idle time and "logs =
out"
users that do nothing in x minutes.

Mika T. Lindqvist
FieldNet Association=20


Other related posts: