Creating profiles not used for login
From OpenSimulator
(Difference between revisions)
m (Removed 'Template:' prefix from template includings and/or changed external-link into internal-link) |
m (Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
{{Quicklinks}} | {{Quicklinks}} | ||
<br /> | <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. | + | 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 | + | 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) | + | (1) Create a normal user account but set the password to something random. |
PROS | PROS | ||
| Line 19: | 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) | + | (2) Add a 'ProfileOnly' flag to the Users table |
PROS | PROS | ||
| Line 30: | 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) | + | (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 40: | 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. | + | * 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 48: | Line 54: | ||
===== | ===== | ||
| − | I suspect that archiving isn't the only potential use for this functionality. | + | 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. | + | 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
 |
Languages: |
|
[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?
