October: Why use "backend_users" table for backend users?

[that0n3guy]

I just started digging into october a little more. I see that there is a backend users table.

Since this is a "backend" (ie backend specific) users table it requires plugins like: https://github.com/rainlab/user-plugin to create its own table. Now you have 2 tables containing user's....

This seems inefficient as now there are 2 models/controllers/components doing a lot of the same things (logging users, creating user accounts, sending emails, etc...).

If I want user groups/roles for the frontend users, I have to create that functionality... even though a lot of this is the backend module: http://octobercms.com/docs/backend/users

Am I thinking about this wrong? Is there a better way?

EDIT (causing title change):

I looked at the code a little more and the october default user model (October\Rain\Auth\Models) uses the "users" table.... so why oh why did backend module use a different table?

[JohannesMP]

+1, this is rather silly. Would be curious to hear dev input on why this is currently set up like this.

[daftspunk]

Backend users and frontend users are entirely different, yet they both inherit the Rain library "Auth" package. So you shouldn't need to rewrite any code here. To have front-end users use groups, we simply need to activate it.

The backend users are packaged as part of the core. The frontend users are supplied via a plugin. Some websites may require frontend users that are far more complex, such as a site like Facebook. Some may not need any at all. So the frontend users supplied by RainLab are entirely optional.

From a coding perspective the separation is intentional to keep things simple for security and organisation. It creates a richer experience to not blur the lines by having "admin-only" content (Go to Admin Panel) polluted everywhere on the front end. Some admins don't need a frontend account. Admins that do can have a pure experience on what it is like to be a normal user, since they need to sign up like one.

I understand the deep need for programmers to stay DRY all the time, but this is one of the exceptions that keeps the platform light on its feet.

[emjayess]

Interesting approach, not what I'm accustomed to (am accustomed to drupal: users, roles, and 'masquerading'); thanks for the explanation.

[that0n3guy]

Gotcha... I come from drupal as well where the difference between user and admin is just permissions.

[WaskiWabit]

I personally like how they have separated the two. For one, you don't have to worry about ACL/RBAC as much.

[smkamranqadri]

My concern is if frontend user have to do some backend stuff then it have to have two user and two password while awkward, is there any way frontend user can be link or something like that?

[LukeTowers]

Sure, you could do one of the following:

1. Build frontend components to manage the data that they need to interact with.
2. Just use backend users in the frontend, this would be similar to how WP does it
3. Hook into the frontend user management events and create an identical backend account for the front end user with the necessary permissions.

Which option you choose is determined by how much functionality the user needs to interact with on the front end vs the backend