Basic user management for the core

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
Post Reply
cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Basic user management for the core

Post by cmb » Fri Dec 12, 2014 12:37 am

Hello Community,

I do not want to turn CMSimple_XH into a full-fledge multi-user system, because that doesn't make any sense IMO. However, the administration of several CMSimple_XH websites is shared by a several users (usually only a few, say two or three). All of these are working under the same account, and, for instance, entries in the log file are undistinguishable (except for the IP on login).

Furthermore we have Memberpages and Register_XH, which allow users to get elevated privileges, but these user accounts are totally unrelated to the admin login, so a user who is both admin and "member" often has to log in twice via different log in forms.

Most, if not all, other CMSs don't have this distinction; you simply log in as user X, and you have the privileges that have been granted to you. So what about having a basic multi-user facility in the core? I'm thinking just about a username and a password (and maybe a full name and an email address), and whether the user is an admin or a user (without any detailed permission system). The main advantage would be a unified log in form, and a unified (and therefore more secure -- due to more widespread testing) authorization. Another benefit would be that the user(name) is known, so their actions could be logged appropriately. The only drawback I can recognize would be that on log in the username has to be given in addition to the password, but that seems to be a minor issue, because that's customary anyway.

Some random thoughts regarding the details:
  • if the user is an admin, XH_ADM (and $adm) will be set to true
  • there need to be a basic form for user management in the backend
  • plugins such as Memberpages and Register_XH should use the basic user management (which needs a respective API), and make their own additions (access permissions for individual sites, etc.)
  • such plugins could add their own user administration, or maybe replace the default administration
I'm not sure if this would work out fine, and I'm not even sure if that's a good idea at all, but I think we should consider it. The thing that bothers me most, is that this feature could easily lead to a lot of feature requests which could try to slowly turn CMSimple_XH's core into a "real" multi-user system (what's hardly feasible, if at all).

Any feedback on this topic by developers, web designers, webmasters and end-users is highly appreciated.

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

maeg
Posts: 525
Joined: Fri Feb 20, 2009 2:27 pm
Location: Agerbæk, Denmark
Contact:

Re: Basic user management for the core

Post by maeg » Fri Dec 12, 2014 6:26 am

That will be cool

+1

svasti
Posts: 1651
Joined: Wed Dec 17, 2008 5:08 pm

Re: Basic user management for the core

Post by svasti » Fri Dec 12, 2014 7:54 am

maeg wrote:That will be cool
+1
+1

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Basic user management for the core

Post by Holger » Fri Dec 12, 2014 11:02 am

cmb wrote:The thing that bothers me most, is that this feature could easily lead to a lot of feature requests which could try to slowly turn CMSimple_XH's core into a "real" multi-user system (what's hardly feasible, if at all).
Hehe, you're right ;-), the first thing come into mind is the request to give some users/authors access to parts of the administration (or not), which would be fine for Extedit_XH as example.
(And I bet that such requests will never end when there is a "basic user management" included :roll: )
cmb wrote:and a unified (and therefore more secure -- due to more widespread testing) authorization.
Yes, if the core checks a username on login, it may result in more security.

OTOH: you have to integrate that basic user management and this way you allow more than one admin account by default. Therefore you have to lock the logins against each other.
So something like Keymaster_XH must be part of the core too.

And yes, there is the benefit to log the logins and maybe some more actions by username appropriately.
But, to be honest, for me it's enough to install Keymaster_XH and share the same account with other users, because I trust them. And I do that only on projects where I really need it.
If one is interested to log each different users login, you can simply add a second input-field for the username and (maybe) compare the result with allowed usernames given in a simple $cf variable. Just for logging that informations, this might be enough. AFAIK this way it works nowadays in CMSimple 4 (but without a check against allowed usernames).

If there'll really come some basic user management, it would be fine to have some real benefits of that feature. I think it would be possible to store a "user-level" to each account and -- depending on that level -- the core enables different features.
We could, for example, store the user level in a new constant beside XH_ADM and allow or disallow things like core-administration, internal filebrowser or loading of plugins-admin.php.
But without those features I'm not sure if adding all that code is usefull...

And even with all this features, XH still remains a single-user-system.

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Basic user management for the core

Post by cmb » Fri Dec 12, 2014 12:36 pm

Holger wrote:
cmb wrote:and a unified (and therefore more secure -- due to more widespread testing) authorization.
Yes, if the core checks a username on login, it may result in more security.
Yes, but that was not my main point. I was referring to user management plugins such as Memberpages and Register_XH, which have their own login security, and this is likely to be less tested and verified against vulnerabilities than that of the core. Furthermore there is no easy CSRF protection for plugins using the user management of those plugins.
Holger wrote:OTOH: you have to integrate that basic user management and this way you allow more than one admin account by default. Therefore you have to lock the logins against each other.
So something like Keymaster_XH must be part of the core too.
I don't think that Keymaster_XH is more than a workaround with several unsolvable limitations. See items 2-4 in the limitations section of its manual. Additionally Keymaster_XH can't prevent all problems when using multiple browser windows/tabs, or with regard to Ajax POST requests (the are by default asynchronous). Instead of Keymaster_XH, I would prefer that the core and the plugins would implement proper handling of concurrency (see http://cmsimpleforum.com/viewtopic.php?t=5855).
Holger wrote:If one is interested to log each different users login, you can simply add a second input-field for the username and (maybe) compare the result with allowed usernames given in a simple $cf variable. Just for logging that informations, this might be enough. AFAIK this way it works nowadays in CMSimple 4 (but without a check against allowed usernames).
That CMSimple 4 feature is close to useless, because the username is not stored for the session, but only taken for the login request and entered in the log file. Further actions can't use the username (for instance, LoginLocker will not easily be able to tell, who is currently logged in, what would be a useful information).
Holger wrote:If there'll really come some basic user management, it would be fine to have some real benefits of that feature. I think it would be possible to store a "user-level" to each account and -- depending on that level -- the core enables different features.
We could, for example, store the user level in a new constant beside XH_ADM and allow or disallow things like core-administration, internal filebrowser or loading of plugins-admin.php.
But without those features I'm not sure if adding all that code is usefull...
At least some of these permissions could be (partly) handled by plugins. For instance, there could be a plugin which replaces the admin menu, and which has a sophisticated permission management. That does not really prevent a user to directly enter URLs of forbidden actions, but at least it would prevent inadvertent actions (and could simplify the menu for them). And there could be an alternative filebrowser which grants certain permissions only to some users.

These plugins would not need to implement the basic user management (particularly the nontrivial authentication), but could rely on the core. Implementing the authorization might be as simple as adding some hidden config options, where a list of permitted users is entered for each feature.
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply