<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Separating login from user service has been one of my concerns for quite some time; doing so allow closed grids to expose only the login service while keeping all other interfaces behind the firewall.<BR><BR>
I would argue that there should be exactly one grid services http port that has to be opened in the firewall; the one that answers the login xmlrpc (and llsd) request.<BR>
<BR>
Everything else should be on other (protected) ports.<BR>
<BR>
Pushing profiles out is also a big +1 for me, as I'm mainly concerned with being able to take that information form other backends.<BR>
<BR>
While we're at it, could we please make the authentication token pluggable, or at least something a little bit less SL-centric than first, last, pass? pluggable credentials class would be best, but even string + pass would be better than the current.<BR>
<BR>Best regards,<BR>Stefan Andersson<BR><BR><BR><BR> <BR>> Date: Mon, 22 Jun 2009 06:33:51 -0700<BR>> From: lopes@ics.uci.edu<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] Shaping the user services<BR>> <BR>> +1 on this, especially separating the login functionality from <BR>> everything else.<BR>> <BR>> (I'll be back working on opensim shortly; I've been traveling and had <BR>> some technical difficulties at the destination)<BR>> <BR>> Melanie wrote:<BR>> > After breaking my head over this for a few weeks, I believe I have <BR>> > figured out how to do this in a sane way.<BR>> > <BR>> > The fallacy was to assume that the login server and the user server <BR>> > would be one entity. That makes things overcomplicated and breaks <BR>> > the architecture all over the place.<BR>> > <BR>> > Now, here is what I have come up with:<BR>> > <BR>> > User Server:<BR>> > - Resolve name to key queries<BR>> > - Resolve key to name queries<BR>> > - Provide avatar picker lists<BR>> > - Manage home region data<BR>> > <BR>> > Authentication server<BR>> > - Create and manage authentication handles (string) and session keys <BR>> > (UUID)<BR>> > - Check passwords or other forms of authentication<BR>> > <BR>> > Login server<BR>> > - Provide the interface for the Linden viewer to log into a grid. <BR>> > Uses the services above, but doesn't contain them.<BR>> > <BR>> > Presence server<BR>> > - Manages last position data<BR>> > - Keeps list of logged in avatars and their locations<BR>> > <BR>> > Alongside with this, a new database is needed. This will not be an <BR>> > upgrade path, but a parallel development with a migration tool.<BR>> > <BR>> > Profile information has no place in this architecture and will be <BR>> > handled exclusively by the profiles module.<BR>> > <BR>> > The user table will specifically be designed to accommodate <BR>> > additional fields and allow getting/setting of such fields.<BR>> > <BR>> > With all user data, a scope identifier will be passed. This will be <BR>> > UUID.Zero in the most common case (Standalone or single grid) but <BR>> > will allow sharing of server processes between multiple logical grids.<BR>> > <BR>> > Comments are welcome.<BR>> > <BR>> > Melanie<BR>> > _______________________________________________<BR>> > Opensim-dev mailing list<BR>> > Opensim-dev@lists.berlios.de<BR>> > https://lists.berlios.de/mailman/listinfo/opensim-dev<BR>> > <BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR></body>
</html>