New Usermanager: discussion

[Tyblitz]

Hi all,

It's been a while since I've started development of a new, more powerful and plugin-friendly user management plugin
(3 months to be exact). It is based on users, permissions, and user groups, and access can be restricted through plugin hooks. I'm nearing the end of a first testable version, although there's no admin dashboard at the moment (it all works by manually modifying XML files). 

I'm going to post the plugin in GS Extend when it has a first more or less stable version, and will also create a proper forum thread. I'm looking for some feedback (see below for the type of feedback) before doing so, so it would be great if testers could give me any. At the moment you can download GS UserMgr from the Github repo or from the attachment in this post. Have a look at the documentation to get started, and if you don't understand something, feel free to ask.

At the moment, you need PHP 5.3+ installed on the (local) server.

Some features:
- 34 standard permissions (top navigation tabs, sidebar items, file or page permissions etc.)
- 5 standard user groups (admin, developer, webmaster, publisher, guest)
- an 'unauthorized' admin dashboard page
- a system for plugin permissions (included in the download is one for i18n_base)

Feedback:

• BUGS: if you find any, please report. This can be anything: .htaccess problems, a tab that shows when it should be hidden, a PHP warning when GSDEBUG is on.
  
• SUGGESTIONS: about which permissions the standard user groups should have, which should be added to/ removed from standard permissions, things that are not clear, which plugin permissions you would really like to have etc.
  
• MOTIVATION: a kind comment is always motivating for further development
  

[Carlos]

That's great news! We really need a plugin like yours.

[Oleg06]

Fully support Carlos. We need a plugin.

[Carlos]

After I quick test,

- With the I18N plugin enabled I get this at the top of page management (load.php?id=i18n_base):
Notice: Undefined index: file in [...]\admin\inc\plugin_functions.php on line 254

- Settings tab redirects to profile.php, which doesn't exist (so I get the 404 page)

- As a publisher I don't see the Theme tab, however I can go to theme.php and edit the theme and components.

[Tyblitz]

After I quick test,

- With the I18N plugin enabled I get this at the top of page management (load.php?id=i18n_base):
Notice: Undefined index: file in [...]\admin\inc\plugin_functions.php on line 254

- Settings tab redirects to profile.php, which doesn't exist (so I get the 404 page)

- As a publisher I don't see the Theme tab, however I can go to theme.php and edit the theme and components.

Thanks, that's very valuable feedback.

• The PHP notice is normal (I got it as well, but now fail to reproduce it), it's actually a PHP bug/inconsistency with the debug_backtrace function. You can 'hide' it by placing an '@' sign in front of all $caller['file'] and $caller['line'] assignments in the plugin_functions.php add_action function.
  
• In GS 3.4 the profile section has its own profile.php file. I thought this was already the case for GS 3.3.12+ but apparently it's not, so I'll fix that.
  
• Ok that's a bug I need to fix
  

[Bigin]

Great job Tyblitz, I have not tested your plugin yet, but I have one question.
When you talk about "permissions", you mean just hiding the elements with css, javascript? What happens if the "unauthorized" admin user send http://your-site.com/admin/deletefile.php?id=page-slug... request?

[Tyblitz]

Great job Tyblitz, I have not tested your plugin yet, but I have one question.
When you talk about "permissions", you mean just hiding the elements with css, javascript? What happens if the "unauthorized" admin user send http://your-site.com/admin/deletefile.php?id=page-slug... request?

Hey Bigin, 

Spot on, on the front-end things are hidden by CSS/ changed with JS where needed.
If an 'unauthorized' user loads an admin page URL manually, it will also redirect to admin/unauthorized.php.
You can see which permissions map to which files (most are access_<phpfilename_without_extension>) in the main plugin file (lines 85 - 127).

This also means that if a user's access_deletefile permission is denied, all sub-permissions which use that file (eg. with a GET param or other back-end checks) will also be denied (e.g. someone who cannot access_deletefile can also not 'delete_page', 'delete_file', 'delete_folder', 'delete_archive').

[mganko]

I'm not sure is I'm missing something or not but after plugin installation and adding <GROUP>publisher</GROUP> to my user file, Plugins tab dissapeared but I can still navigate to http://blabla/admin/plugins.php and enable/disable plugins, enter configuration of plugins.

Some time ago I created plugin that allows to lock access to configuration of plugins by allow/disable some url queries:
http://get-simple.info/extend/plugin/plugin-lock/854/

[Tyblitz]

I'm not sure is I'm missing something or not but after plugin installation and adding <GROUP>publisher</GROUP> to my user file, Plugins tab dissapeared but I can still navigate to http://blabla/admin/plugins.php and enable/disable plugins, enter configuration of plugins.

Some time ago I created plugin that allows to lock access to configuration of plugins by allow/disable some url queries:
http://get-simple.info/extend/plugin/plugin-lock/854/

Hey mganko,

Thanks for your input; yes normally you shouldn't be able to navigate manually either. I think this should be fixed in the latest version on Github. Also, your plugin is a great start for querystring-based back-end access rule management (also like the UI), I'll want to look into how you coded it for ideas

[Tyblitz]

@Carlos, the PHP notice with I18n_base, it disappears if the permissions file is named differently than i18n_base.php.
However, it's more likely got something to do with i18n, as for other plugins I don't have this problem.