Handling Different Types of Users

I’m in the process of building an e-commerce site. (For anyone who has been on SitePoint in the past 20 years, you will realize it’s not going very fast!!)

What is the best way to group and label different types of people?

Original Plan:

User (super-class/table)

[INDENT]- Visitor (sub-class/table)(unregistered)

  • Customer (sub-class/table)(registered)
  • Admin (sub-class/table)(registered super user)[/INDENT]

Points of Contention:

1.) Have One Class/Table called “User” - it will be a pain to have to manage sub-classes/tables and move people around as they change roles.

2.) Create a separate Role-Class/Table - this will allow you to much more easily manage User-Roles and promote/demote people on the fly.

3.) What is a ‘Customer’? - I say it is anyone who is shopping regardless of whether they are a Returning Customer or a New Customer. (Try telling your boss that the people waiting outside to try your world famous <whatever> are not yet ‘Customers’?!)

4.) How much to track from “Visitors”? - Is it physically possible or desirable to save a “Visitor’s” (i.e. no Customer Account yet) shopping cart in the back-end database and then somehow match that shopping cart back up with them when they return if they haven’t registered yet?!

Also, I think writing what “Visitors” do on the backend would be helpful as far as metrics go. if they don’t register and buy something in 30 days, delete the records but keep the shopping-patterns data for reporting and future planning.

What do you think?

TomTees

If you want users to access just the web pages their access level allows and not also the web pages of any subordinate role then that is fairly easy to set up as well.

At the top of each page you could have

 
if(!isset($_SESSION['access_level']) || $_SESSION['access_level']) != 1) {
   echo 'you are not an authorised user';
   die();
}

You set the check value of $_SESSION[‘access_level’] in the 1st line to the appropriate role/access level for that web page.

When is it you propose that this complete change of the way just about all systems work be implemented so as to take away the single account that some people currently have that needs to be replaced by two, three, or more accounts under your new approach?

How many people do you think will want admin etc accounts if they have to log out of their normal account and log back in via a different account to use it - probably not many in which case most sites requiring logins will then disappear because there is no one to administer it.

For example the backend of vBulletin assigns everyone a main role and then has checkboxes to attach all the other roles that are available on that one login. If I had to have two accounts here - one to make normal posts and one for moderating the forum then the moderator login would never get used.

Hello…

Would I expect that you have to log on using an Admin ID to be able to change content and features on SitePoint and a separate Member ID to just be able to make a simple post on SitePoint??

YES!!

TomTees

explain? i should think it was obvious

how would you feel if you had to sign on to sitepoint with two different userids, depending on whether you were posting a new thread or answering an existing one

p.i.t.a. (and i don’t mean People Ingesting Tasty Animals)

Tom say you make this site, in 6 months you want to buy from it, will you easily know which name is the admin and which you can use to buy?.. then think of Rudy’s comment

Why do you say that?

Please explain!

TomTees

ok, I am assuming a user will be assigned only 1 role.

If that is the case you could have just 1 user table. One of the columns in that user table could be called fldAccessLevel where access level 1 = admin, 2 = registered customer.

Then every time a request is made for a web page from a client browser, you check if the user is logged an the time, and if so what the current session access level is set to. If is 1, the user can see any web page. If it is 2, then the user can see all the web pages except those that require a fldAccessLevel = 1 (admin web pages). If no session access level is currently set, then the user is not logged in and so can view only the public web pages.

See my original post.

TomTees

It might help visualise possible solutions if you post the actual role names. Then it should be easier to offer solutions on how to best structure them in the database.

you won’t have to move users around if the role is kept separate from the user who has the role

and what if a user has more than one role?

ask yourself what would have to change about your proposed table design if you did not use those three “sub-class” tables

If one User had one Role, it would just be adding a UserRole field.

If one User could have many Roles, then it would be a many-to-many

[INDENT]User -||-------<-UserRoleDetails->-------||- UserRole
[/INDENT]

(Crow’s Foot Notation for all of the “cool” people here…)

TomTees

i think this is suboptimal, but hey, it’s your design…

When I developed for my very large university (45k+ students), I could not go to www.uni.edu/admin and there was the world. I have to log in via kernal, or sftp program… I had 1 username for my three roles: student, staff, developer.

actually, no :slight_smile: :slight_smile:

[QUOTE=TomTees;]In fact, good security would prohibit a super user from logging in as a regular user from the outside web…[/quote]i think you are making up rules here, because “good security” says no such thing

[QUOTE=TomTees;]I would never allow an “Admin” to log in and shop from the main page of my website. Never!![/quote]well, like i said a whole bunch of posts ago, it’s your system, so you are free to do it the way you want…

It’s a continuum, but I come back to the main question, which is, “Why would a Super Admin need or want to Shop (minus for testing purposes)?!”

It depends on the size of the system, what is at risk, and numerous other factors.

But in the business world I’ve usually seen things segregated pretty clearly like I’m describing.

“Admins” have no reason or right to be shopping on a web-facing e-commerce site. Their role and purpose is on the backend which is protected in many ways (VPNs, Firewalls, Physical Security).

You could never get PCI Compliance (or any other type of security certification) by allowing “Root” users to be accessing mission-critical systems from the outside via the Internet. Never!!

Does this apply to my website or future business? Not as much so.

I just chose the design for simplicity! :cool:

If you run a usergroup for your favorite sports team, is what you are proposing good enough? Probably so.

But if that is how lax Sitepoint is - beyond simple “Forum Admins” - then I’d be really shocked!

An interesting debate nonetheless! :slight_smile:

TomTees

Moderating Forums is a little different than “root” access to the entire website.

I bet you couldn’t log in as a “Super Admin” to Amazon.com from the Web. You would probably be required to log in at the very least to a VPN, if not physically from a computer on-site.

Is my website at that level? Of course not. But early I got a strange look for saying One User Account has One Security Role.

Why would anyone want to shop on an E-commerce site for personal reasons, away from work, and to also expect to be able to have the rights to bring the entire site to a screeching halt in a few keystrokes?!

TomTees

Most systems handle that by requiring someone with an admin account to enter their password a second time when requesting access to the admin only functionality.

So when “Joe Super Admin” logs in to his “Super Admin Account” at the public library so he can buy a DVD, and then he gets distracted by a pretty girl and walks off without logging out anyone who does access it can only access the regular user functionality because to access the back end requires entering the password again (unless Joe was in the backend when he forgot to log out).

The general rule is that whenever someone tries to access a more restricted area of the site that they must enter their password again so that if someone did forget to logout that access is limited to whatever part of the site they were logged into at that time.

Why are we debating security when that wasn’t even the point of my original post??

Nice side discussion, but not what I set out to discuss.

TomTees

If this site ever gets built, it will be a ma-and-pa shop, so all of this would be a non-issue.

I don’t know how Amazon or SitePoint handles this issue.

However, I can say with a high degree of certainty, that “Admin” accounts are intuitively different to anyone using them than a “User” account.

They usually lead to different areas, different screen, and have entirely different log in steps.

I would never allow an “Admin” to log in and shop from the main page of my website. Never!!

In fact, I would probably have a security rule stating that you cannot log in and shop from the main page of the website.

If you allow that, then what happens when “Joe Super Admin” logs in to his “Super Admin Account” at the public library so he can buy a DVD, and then he gets distracted by a pretty girl and walks off without logging out?!

Isn’t all of this pretty obvious??

Yes, One Person can have multiple Account Types, but only One User Account can only have One Set of Security Rights.

You want “Admin” accounts to be segregated from “User” accounts on many levels…

TomTees