Multi-Profile Mod?

[irbrian]

I don't believe I've mentioned this yet -- I would really like to have a multiple-profiles mod. Basically, I would like to allow my users the option to register and quickly switch between a maximum number of Profiles, all associated with the same username/e-mail (and ideally a single "primary" profile, for keeping track of and displaying information about the user). That way they could login once, and then switch between their profiles any time for posting.

One way I thought about doing this, is adding a required "owner" field to the members table. Then when users register there could be a check box on the registration page which, if checked, would require them to enter the username and password of an existing user instead of a new username and password (also making the requirement for an e-mail address optional).
In that case it would place in the 'owner' field the user ID of the registered user who was specified as the owner. If the checkbox was left blank and the profile was new, the owner field might have a 0 or some other flag which would be interpreted as being a primary profile.

Then on the board index there could be a drop down list, similar to the new Bookmarks list, which shows a list of profiles associated with the current user

I need something like this for an RPG board I'm running, but I'm afraid I just don't have the time to design and code it, so if any modders are looking for a really slick mod idea, this would be a really unique feature, I don't know of any other boards that offer the ability to have multiple profiles.

Naturally, many administrators may find this to be an annoyance, but on some boards it could be very useful, if used within certain parameters.

[tdodnz]

Ok the way id do this is create it so that a member has to confirm their email account by clicking on the confirm thing in an email that would be sent, then you could just put a line in the profiles page with a simple sql select statement
$request = mysql_query ("SELECT * FROM {$db_prefix}members WHERE memberEmail = "$email'")
Then you would put this into an array which is inside a while loop to display the member names then they just click on the link and it refreshes the profiles page but opening up a different username by a short if statement.

[irbrian]

Umm.. seems like what you're recommending is just displaying a list of all the member profiles associated with a given E-mail address. But thats not what I want (although that wouldn't work currently anyway, since YSE does not currently allow multiple accounts under one e-mail address..).

a member has to confirm their email account by clicking on the confirm thing in an email that would be sent

And this is a way to verify the existence of an e-mail address, which is perhaps a good idea but again not really relevant. Sorry.

What I want is actually for users to be able to log out then back in under a different username (still associated with their primary username) in one click.

I suppose that using the e-mail verification thing would be a good alternative to only allowing one account per e-mail address, however. And the query $request = mysql_query ("SELECT * FROM {$db_prefix}members WHERE memberEmail = "$email'") is a good way to list the profiles associated with a particular e-mail address.

But here's what I think I'm going to do instead. I am going to add a column to the members table called 'ownerName' -- previously existing, and primary, accounts will default to the same username as the 'memberName' field. Then a modification to your suggested query: $request = mysql_query ("SELECT memberName,ownerName,realName FROM {$db_prefix}members WHERE ownerName = "$???['currentMember]") will populate a drop down list, and a Switch button will perform the same actions as the logout and login2 functions of the board, logging in with the selected memberName.

I'm concerned about whether there will be any security repercussions, though, since this would ideally bypass the necessity for a password. Or maybe there could be a required password box below the drop down list. Or... well, I'll figure something out.

Changes will also need to be made to the sign up process, though. In particular, the following fields must be added to the registration form:
Account Owner (Leave Blank if this is a New Primary Account)
and
Owner Password

Naturally, if the two fields are completed, then the register function would have to verify the owner user/pass and then add the owner username to the 'ownerName' field for the new account. Otherwise the ownerName would be set to the newly registered memberName.

Note: Sorry for the mix of actual and hypothetical function, variable, and tablename references; I don't remember them all.

[[Unknown]]

I would recommend doing it by ID_MEMBER.... and you can simply require (by means of setting it when they have a child account) all passwords to be identical to the owner password.  Then, just have it check against the owner password.  No cheating.

-[Unknown]

[tdodnz]

Well I would do what [Unknown] said and use the member id and insert new members as such.

They would be inserted without the login details (no username or password) but the same member ID but the other thing is if you want this mod it will make everything else screwy, as many things use the members details.

So in fact you would have to have no member ID, no username, no password, so yeah actually, you do need another column unless you wish to modify most of the forum.

The new colum wud just be the members username and on sign up their usrname would also be added to here.

To create the new user as such it would have to be done through the profile page for security reasons, and you would have to write your own insert statement else it will get messed up from the forums security stuff for the registration.

[irbrian]

I guess I don't see why using the ID_MEMBER is any more efficient or better than using the memberName. If I remember right, passwords are actually matched by memberName, not by ID, so it seems more efficient to use the memberName. But I do agree that the password should be the same. If anyone can come up with a good reason why the ID would be better, then by all means lay it on me.

So here's the new solution as I see it:

First, I'll add an 'owner' column to members table. That column will always contain the memberName of the owner -- naturally, it would be the same value as the memberName column if its a primary account.

On the registration form there will be a new section with the following options:
Is this a sub account of an existing account?  [   ]
Owner username:  [                           ]
Owner password:  [                           ]

Now the registration code is modified:

Code Select Expand

if sub-account option is checked, then {
  if owner username and (encrypted version of password) match, then {
    put owner username value into the 'owner' column;
    put (encrypted version of owner password) into new account password column;
    }
  }

continue registration process.
Still a couple tricky parts though:

1) Can't use the owner memberName for the child account's memberName because unique memberNames most definitely are a necessity, so the user would still have to specify a username. The result of this is that the user could still sign in under the child account directly, and would have access to other accounts from there. Come to think of it, this is necessary anyway, because you have to know a user's memberName to send them an IM.

2) The option for users to change their password in their profile settings would have to be disabled.

I would like to come up with an alternative where the user could still specify their own password, without having to type their password every time they wanted to switch profiles.. for one thing it eliminates the complication of having to drastically alter the profile settings screen.

Comments, feedback, and especially ideas are still welcome! I'm seriously considering spending time I don't have to develop this mod.

Edit: Not sure why I put the code tag at the top of the page before..

[[Unknown]]

INTs are faster than whatever memberName is so I would recommend using it as an identifier.

That's a fairly good solution.  Each account would have a seperate username, same password.  To switch between accounts, you would only have to have the form (the list of child accounts at the top) send them to login3, (a new action you would likely need to make) and look at their current login cookie's password and use that to login to the new account.  If password verification fails, kick them.

login3 would then send them to the page they were on (ie. whichever topic they were browsing) and allow them to continue where they left off.

If the owner value is 0 (meaning it has no owner) allow a password change, otherwise print out "You can only change $owneraccount's password" (where $owneraccount is the owner's realName.)

This would work fairly well, I should think...

-[Unknown]

[tdodnz]

I don't think that he wants to have to have them re login and would rather have them just select a different profile not have a new membername/password.

So you just do what I said above

[[Unknown]]

No, they would have to relogin as a different user to post as a different one.  However, if the process were automated (a drop down box to switch u/ns) it would do a world of good.

Plus, it wouldn't be much less secure, as it would STILL require the right password.

In fact, you could have another cookie set - owner.  And it could just check the password against that.  But that would take more modifications. I recommend just making it transparent.  Make the user think she or he is just changing names, make the script think he or she is logging in again.

-[Unknown]

[tdodnz]

Yeah I spose but still multiple profiles/memberlogins are essentually the same thing but the use only has a single login name and they can be viewed as different people I don't know now u put up a good argument have to wait for the original poster to tell us  

[irbrian]

INTs are faster than whatever memberName is so I would recommend using it as an identifier.

You may have a point about integers being faster. I don't think it would ever become a noticeable difference but certainly every little optimization adds up. The biggest slowdown, though, is just in adding a new query. At any rate it doesn't matter all that much, but since the ID_MEMBER is already the official identifier, I guess I'll just use that.
 

That's a fairly good solution.  Each account would have a seperate username, same password.  To switch between accounts, you would only have to have the form (the list of child accounts at the top) send them to login3, (a new action you would likely need to make) and look at their current login cookie's password and use that to login to the new account.  If password verification fails, kick them.
 
login3 would then send them to the page they were on (ie. whichever topic they were browsing) and allow them to continue where they left off.

Using the existing cookies is a perfectly viable option, its what I was considering originally, I just want to make sure its not going to cause any security holes that people will be complaining about later.
 
As for sending them back to where they were before, I can just model the base functionality of login3 after login2.
 

I don't think that he wants to have to have them re login and would rather have them just select a different profile not have a new membername/password.

No, they would have to relogin as a different user to post as a different one.  However, if the process were automated (a drop down box to switch u/ns) it would do a world of good.

That's the plan.
 
There's one more issue that concerns me, actually... the Change Password option in the profile settings for the main user. I'd have to adjust it so that the password is changed for ALL sub-accounts. Seems like a pain.

In fact, you could have another cookie set - owner.

Maybe thats the solution. In this scenario, the mod could require that the Owner cookie be set in order to switch profiles, meaning that at SOME point the user would have to login under the primary account. Then as long as the owner cookie is set the user would be allowed to switch to a profile with that owner. This way it wouldn't matter what the password was.

[irbrian]

Additional comments? Suggestions? Questions? Other feedback?

Anyone?

[tdodnz]

are you making it??

[irbrian]

To be truthful I haven't decided. I'm certain its well within my capabilities to make, but I'm just so limited on time these days and have so many other projects going on, that its risky for me to make a committment to a mod that others may not even care to use.

I do have the next three days off, though, so I may be able to get quite a bit of the work done then... on the other hand if you're anxious to make this mod yourself, I won't stop you. I may decide to make changes later with your permission, but I won't stop you. Just let me know first so that I don't waste my valuable time working on a mod someone else is developing.