[Opensim-dev] RFC: Ways of creating profiles for creators who will never log in

Brianna wwwench at gmail.com
Thu Mar 26 23:34:58 UTC 2009


In the process of making this short HyperGrid YouTube...
http://www.youtube.com/watch?v=Lz-x7jn2hws&feature=channel_page
I notice more HG nodes understandability shutting the doors to scripted 
objects for security reasons. It would be great to have a 'passport' scheme 
that would allow travel with boats and ballooning in the future days from 
known Grid citizens.


----- Original Message ----- 
From: "Diva Canto" <diva at metaverseink.com>
To: <opensim-dev at lists.berlios.de>
Sent: Thursday, March 26, 2009 3:09 PM
Subject: Re: [Opensim-dev] RFC: Ways of creating profiles for creators who 
will never log in


> Whatever you decided to do (option 3 seems the cleanest), this will
> probably also be used in the Hypergrid, to keep track of foreign users.
> I need that! :-)
>
> Justin Clark-Casey wrote:
>> Hello,
>>
>> For Inventory Archives I plan to preserve item creator information.  When 
>> the archive is loaded I would like to recreate
>> these profiles where possible/necessary (grid operators can choose not to 
>> allow this and that will be the default, I
>> expect).
>>
>> However, unless an item creator has an account on the OpenSim to which 
>> the archive is loaded, they shouldn't be able to
>> login to that instance.
>>
>> So far I've thought of 3 ways to create a profile without automatically 
>> allowing login.
>>
>>
>> (1)  Create a normal user account but set the password to something 
>> random.
>>
>> PROS
>> * Doesn't require any changes to what we have today
>>
>> CONS
>> * Creates user accounts which are never intended to be used for login
>> * No way to distinguish archive created accounts from legitimate accounts
>> ~~~~~
>>
>> (2)  Add a 'ProfileOnly' flag to the Users table
>>
>> PROS
>> * Minimal changes to what we have today
>> * Makes it clear that an entries has been created for its profile only, 
>> which can be used as a flag to disallow logins
>>
>> CONS
>> * Creates user accounts where many details will be irrelevant unless item 
>> creators then get accounts on the instance.
>> * Complicates administration tasks (e.g. create user).
>> ~~~~~
>>
>> (3)  Separate the current 'users' table into 'userprofiles' and 'users' 
>> tables.
>>
>> 'userprofiles' will largely contain all the metadata about a user that 
>> you can see in the profile on the Linden Labs
>> Second Life client today (name, about, interests, 1st life, etc.).
>>
>> 'users' will contain the data associated with a particular account 
>> (passwordHash, passwordSalt, homeRegion,
>> homeLocationX, etc.)
>>
>> PROS
>> * Makes it possible to create user profiles without creating user 
>> accounts.
>> * Makes it possible to have somewhat separate profile and authentication 
>> plugins allow mix & match.  However, the reuse
>> of avatar name as the login identifier makes things a bit awkward.
>> * Simplifies database understandability - the only people in the 'users' 
>> table are those with actual accounts, though on
>> the other hand this does create 2 tables instead of 1.
>>
>> CONS
>> * Short term adjustment pain for systems accessing OpenSim's databases 
>> directly
>> * Complicates administration tasks (e.g. create user).
>> ~~~~
>>
>> I suspect that archiving isn't the only potential use for this 
>> functionality.  For instance, the Hypergrid may also find
>> it useful to preserve user information when a user rezzes an object on a 
>> foreign system.
>>
>> Of the above approaches, I prefer (3) over (2) since it seems to me to be 
>> the better long term approach even if there is
>> some short term pain.  I'm don't think that (1) is a good option.
>>
>> I've reproduced most of text at 
>> http://opensimulator.org/wiki/Creating_profiles_not_used_for_login for 
>> reference.
>>
>> Comments?
>>
>>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev 




More information about the Opensim-dev mailing list