Creating profiles not used for login

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(New page: '''Authors''': User:justincc In Inventory Archives I plan to preserve item creator information. When the archive is loaded I would like to recreate these profiles where possible (gri...)
 
m (Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
__NOTOC__
 +
{{Quicklinks}}
 +
<br />
 +
= Status =
 +
 +
Not done. Creator information is preserved without recreating profiles.
 +
 +
= Text =
 +
 
'''Authors''': [[User:justincc]]
 
'''Authors''': [[User:justincc]]
  
In Inventory Archives I plan to preserve item creator information. When the archive is loaded I would like to recreate these profiles where possible (grid operators can choose not to allow this and that will be the default, I expect).
+
In Inventory Archives I plan to preserve item creator information. When the archive is loaded I would like to recreate these profiles where possible (grid operators can choose not to allow this and that will be the default, I expect).
  
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.
+
Unless an item creator has an account on the OpenSimulator 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 achieve this
 
So far I've thought of 3 ways to achieve this
  
  
(1) Create a normal user account but set the password to something random.
+
(1) Create a normal user account but set the password to something random.
  
 
PROS
 
PROS
Line 16: Line 25:
 
* Creates user accounts which are never intended to be used for login
 
* Creates user accounts which are never intended to be used for login
 
* No way to distinguish archive created accounts from legitimate accounts
 
* No way to distinguish archive created accounts from legitimate accounts
=====
+
=====  
  
(2) Add a 'ProfileOnly' flag to the Users table
+
(2) Add a 'ProfileOnly' flag to the Users table
  
 
PROS
 
PROS
Line 27: Line 36:
 
* Creates user accounts where many details will be irrelevant unless item creators then get accounts on the instance.
 
* 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).
 
* Complicates administration tasks (e.g. create user).
=====
+
=====
  
(3) Separate the current 'users' table into 'userprofiles' and 'users' tables.
+
(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.).
+
'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.)
 
'users' will contain the data associated with a particular account (passwordHash, passwordSalt, homeRegion, homeLocationX, etc.)
Line 37: Line 46:
 
PROS
 
PROS
 
* Makes it possible to create user profiles without creating user accounts.
 
* 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.
+
* 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.
 
* 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.
  
Line 45: Line 54:
 
=====
 
=====
  
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.
+
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 not seriously considering (1).
+
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 not seriously considering (1).
  
 
Comments?
 
Comments?

Latest revision as of 22:18, 3 March 2012


[edit] Status

Not done. Creator information is preserved without recreating profiles.

[edit] Text

Authors: User:justincc

In Inventory Archives I plan to preserve item creator information. When the archive is loaded I would like to recreate these profiles where possible (grid operators can choose not to allow this and that will be the default, I expect).

Unless an item creator has an account on the OpenSimulator 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 achieve this


(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

[edit] =

(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).

[edit] =

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 not seriously considering (1).

Comments?

Personal tools
General
About This Wiki