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

[Stefan Andersson]

Justin,

 

whilst you're at it, could you have a look at the feasabilty of just adding the url to the user profile on the user service on the originating grid?

 

We should try to move from guid/local to url/global in everything we do, even if in babysteps.

 

If we could let the user server serve a controlled subset of the user profile to the world, that could be used for preserving a link to the original creator.


So, instead of having creator=<someGuid> and then have to re-create that profile locally, we could have creator=http://users.osgrid.org/users/justincc/


Best regards,
Stefan Andersson
Tribal Media AB



 
> Date: Thu, 26 Mar 2009 21:00:16 +0000
> From: jjustincc at googlemail.com
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] RFC: Ways of creating profiles for creators who will never log in
> 
> 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?
> 
> -- 
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090327/edcbb960/attachment-0001.html>