User Demo Admin Plugin Guide for Cotonti

Version: 5.0.0
Author: webitproff
License: BSD
Requirements: Cotonti (current version), users module

Table of Contents

1. Overview of the plugin and its purpose
2. Plugin business logic
   • 2.1. Creating the "Demo Admin" group
   • 2.2. Assigning access rights
   • 2.3. Protection against write operations
   • 2.4. Creating a demo administrator user
3. Interaction of demo admin with the site interface
   • 3.1. What can be viewed
   • 3.2. What operations are prohibited
   • 3.3. Behavior when attempting to save
4. Technical memo on installing and removing the plugin
   • 4.1. Installation
   • 4.2. Removal
   • 4.3. Installation file (install.php)
   • 4.4. Removal file (uninstall.php)
   • 4.5. Plugin file structure
5. Security warnings
6. Recommendations for further modification
7. Conclusions

1. Overview of the plugin and its purpose

The User Demo Admin plugin is designed to create users with a special access level — "demo administrator" or "read-only administrator".

Main goal — to provide limited access to the Cotonti administration panel to trusted individuals (audit, training, demonstration) without the risk of accidental or intentional modification of settings, content, rights, or site structure.

The "User Demo Admin" plugin is a completely new and experimental extension for CMF Cotonti. 
Use it at your own risk. 
The plugin has not been fully tested to make bold statements. 
For the most part, the plugin solves the tasks that are set for me (as a developer of extensions and templates), but I recommend that you use it with extreme caution!

A user from the Demo Admin group will be able to:

• log in to the administration panel;
• view almost all admin sections, including settings, user lists, pages, modules, and plugins;
• see the interface and data as a full administrator sees them.

At the same time, they will not be able to:

• save changes (configuration, content, rights);
• delete or edit records;
• install/uninstall extensions;
• perform any operations that change the system state.

In fact, the plugin imitates a "view-only" mode for the admin panel, similar to the demo mode in OpenCart or PrestaShop.

Important: the plugin does not modify the Cotonti database structure. Only standard tables are used: cot_groups, cot_auth, cot_groups_users, cot_users.

2. Plugin business logic

2.1. Creating the "Demo Admin" group

On the first call to the plugin (or during its installation), the function cot_user_demo_admin_ensure_group() checks for the existence of a group with the specified alias (default demo_admin). If the group is not found, it is created in the cot_groups table with the following parameters:

• grp_name = "Demo Admin"
• grp_title = "Demo Admin"
• grp_level = 50 (high enough to appear as a privileged group)
• grp_alias = demo_admin (configurable)
• grp_skiprights = 0 (rights are used)
• grp_pfs_maxfile / grp_pfs_maxtotal = 0 (file upload is prohibited)

2.2. Assigning access rights

The plugin uses the standard Cotonti rights system based on bit masks in the cot_auth table. The following rights are set for the demo administrator group:

Bit masks:

• R = 1 (read)
• W = 2 (write)
• A = 128 (administrative access)

For admin, 129 = 1+128 is set, which gives the right to enter the admin panel, but does not give write permission (W) and additional privileges (1-5).
All other areas receive only R = 1.

Rights to structure categories. The plugin grants R rights not only to root sections of modules (auth_option = 'a'), but also to each structure category (for example, all categories of the page, forums modules, etc.). This is necessary for the demo administrator to see materials whose access is checked through category rights. Without this step, the user would not even see public pages and records.

For all rights, auth_rights_lock = 254 is set, which blocks changing these rights through the standard editing interface (R, W, A, and additional bits are locked). This prevents accidental expansion of demo group rights by the demo user themselves.

2.3. Protection against write operations

Since the standard Cotonti rights system cannot completely prohibit writing when having admin access (many scripts check only cot_auth('admin', 'a', 'A')), the plugin adds an additional layer of protection through a global hook.

In the file user_demo_admin.global.php, a check is implemented:

• If the current user belongs to the Demo Admin group and is in the admin panel, then:
  • the variable Cot::$usr['auth_write'] is forcibly set to false;
  • the incoming request is analyzed:
    • if method is POST → considered a write attempt;
    • if parameter a (action) is in the dangerous list (update, save, add, edit, delete, install, uninstall, config, rights, etc.) → write attempt;
    • if section m=config or m=rights is requested → write attempt.
• When a write attempt is detected:
  • $_POST and $_REQUEST arrays are cleared;
  • a warning is displayed: "Demo mode: changes are not saved...";
  • a redirect to the previous page (or to the admin main page) is performed.

Thus, any POST requests and actions that usually lead to data changes are blocked before the main logic is executed.

2.4. Creating a demo administrator user

In the plugin's admin interface (the "Create user" tab), the administrator can enter a name, email, and password. After validating the data (length, format, uniqueness check), the standard function cot_add_user() is called with the main group $groupId (the Demo Admin group ID). The created user immediately receives all rights of this group.

No activation email is sent ($sendemail = false).

3. Interaction of demo admin with the site interface

3.1. What can be viewed

After logging into the admin panel, the demo administrator will see the standard left menu and can open the following sections:

• Admin home page (overview information).
• Settings (site configuration) — all tabs: general, security, performance, themes, etc. (view mode).
• Users — user list, search, profile viewing (without edit buttons).
• Pages (if the page module is installed) — page list, category structure, content viewing.
• Extensions — list of modules and plugins, their settings (view only, "Save" buttons will be inactive or their click blocked).
• Site structure — viewing categories and parameters.
• Access rights — interface for viewing group rights (with possible display, but without saving).
• Tools, Files, Cache, and other sections available to a regular administrator.

Thanks to the R rights set for all modules and categories, the demo admin will not see "No access" messages when trying to open pages.

Below is a summary access table:

Important: the demo user is not a super administrator. They simply have the right to log into the admin panel and read.

3.2. What operations are prohibited

All operations that change the system state will be blocked:

• Saving any settings (configuration, themes, modules, plugins).
• Adding, editing, deleting users, pages, categories, files, etc.
• Installing, updating, removing extensions.
• Changing access rights.
• Clearing cache, executing SQL queries, and other dangerous actions.

Formally, the interface may contain "Save", "Update", "Delete" buttons, etc., but when trying to click them (i.e., sending a POST request or an action classified as dangerous), protection will be triggered.

3.3. Behavior when attempting to save

When the demo admin clicks the save button, the following happens:

1. The browser sends a request to the server (usually POST with parameters).
2. The plugin's global hook intercepts this request.
3. If the user is identified as demo admin and the request contains dangerous signs (POST or a in the prohibited list), the following actions are taken:
   • $_POST and part of $_REQUEST are cleared;
   • a warning message is shown (usually a popup notification);
   • a redirect to the previous page or admin main page occurs.
4. The target script (e.g., saving configuration) does not execute, data is not changed.

4. Technical memo on installing and removing the plugin

4.1. Installation

1. Copy the user_demo_admin folder to the plugins/ directory of your site.
2. Log in to the Cotonti administration panel with a full-rights account.
3. Go to Extensions → Plugins.
4. Find the User Demo Admin plugin in the list of available plugins.
5. Click Install.

After installation:

• The cot_user_demo_admin_ensure_group() function will be executed (if not called before), creating the group and rights.
• The plugin will appear in the admin panel under Administration → User Demo Admin (or via the link admin.php?m=other&p=user_demo_admin).

It is recommended to go to the plugin after installation, open the "Rights" tab, and click "Save rights" — this ensures recreation of rights for all current structure categories.

4.2. Removal

1. In Extensions → Plugins, find the installed User Demo Admin plugin.
2. Click Uninstall.

During removal, the uninstall.php script is executed, which:

• finds the group by alias;
• moves all users of this group to the main Members group (ID = 4);
• deletes all user-group links in the cot_groups_users table;
• deletes all group rights from the cot_auth table;
• deletes the group itself from cot_groups;
• clears the authorization cache (cot_auth_clear('all')).

Important: after removing the plugin, users who belonged to the demo group lose admin access and become regular members.

It is recommended to manually delete or move demo users before removal.

4.3. Installation file (install.php)

defined('COT_CODE') or die('Wrong URL');

require_once cot_incfile('user_demo_admin', 'plug', 'functions');

$groupId = cot_user_demo_admin_ensure_group();

if (!$groupId) {
    cot_error('Failed to create Demo Admin group');
}

What it does:

• Includes the plugin's function file.
• Calls cot_user_demo_admin_ensure_group(), which creates the group and assigns all necessary rights.
• If the group cannot be created, outputs an error message.

4.4. Removal file (uninstall.php)

defined('COT_CODE') or die('Wrong URL');

$alias = Cot::$cfg['plugin']['user_demo_admin']['group_alias'] ?? 'demo_admin';

$group = Cot::$db->query(
    'SELECT grp_id FROM ' . Cot::$db->groups . ' WHERE grp_alias = ? LIMIT 1',
    [$alias]
)->fetch();

if ($group) {
    $groupId = (int) $group['grp_id'];

    Cot::$db->update(
        Cot::$db->users,
        ['user_maingrp' => COT_GROUP_MEMBERS],
        'user_maingrp = ?',
        [$groupId]
    );

    Cot::$db->delete(Cot::$db->groups_users, 'gru_groupid = ?', [$groupId]);
    Cot::$db->delete(Cot::$db->auth, 'auth_groupid = ?', [$groupId]);
    Cot::$db->delete(Cot::$db->groups, 'grp_id = ?', [$groupId]);

    cot_auth_clear('all');
}

What it does:

• Finds the group ID by alias.
• Updates user_maingrp of all users in this group to the standard Members group (4).
• Deletes links in cot_groups_users, rights in cot_auth, and the group itself.
• Resets the rights cache.

4.5. Plugin file structure

plugins/user_demo_admin/
├── user_demo_admin.setup.php          — registration and settings
├── user_demo_admin.global.php         — write protection + stub
├── user_demo_admin.admin.php          — main interface (tools)
├── inc/
│   └── user_demo_admin.functions.php  — all business logic
├── lang/
│   └── user_demo_admin.ru.lang.php    — Russian language
├── tpl/
│   └── user_demo_admin.admin.tpl      — admin template
└── setup/
    ├── user_demo_admin.install.php
    └── user_demo_admin.uninstall.php

5. Security warnings

The User Demo Admin plugin provides fairly broad access to administrative information. Despite all the measures taken, the following risks should be considered:

1. Bypassing protection through direct requests.
   Theoretically, knowing the Cotonti structure, a demo user may try to send a non-standard POST request that does not contain the prohibited a parameter. The protection blocks most scenarios but does not guarantee 100% isolation.
2. Leakage of confidential data.
   The demo admin can see user emails, security settings, file paths, list of installed extensions, and other sensitive information. Do not give such access to strangers.
3. Performance impact.
   A user with admin access can open heavy pages (e.g., the list of all users with many records), which can load the server. Limit the number of demo users if necessary.
4. Changing rights through the standard interface.
   The plugin locks group rights via auth_rights_lock=254, but if someone with full access accidentally removes the lock by directly editing the database, the demo admin may elevate their rights. Regularly check the integrity of settings.
5. Incompatibility with some third-party plugins.
   Some plugins may save via AJAX or alternative methods not intercepted by the standard global hook. In such cases, protection may not work. Test all critical extensions before granting demo access.
6. The demo user's password must be strong.
   Do not use demo, 123456, etc. It is recommended to generate a reliable password.
7. Do not keep demo users for a long time.
   After the demonstration or testing is complete, delete or block such users.
8. The super administrator can always change the rights of the Demo Admin group.
   Make sure the group rights are not accidentally expanded.

Recommendations:

• Use the plugin only for a limited circle of trusted individuals.
• Do not share demo credentials publicly.
• Periodically check that the group and rights have not been changed.
• If unauthorized change attempts are detected, immediately delete the demo user.

6. Recommendations for further modification

The plugin can be extended and adapted to specific tasks. Consider possible directions:

1. Finer tuning of prohibited actions.
   In user_demo_admin.global.php, additional parameters or URL patterns can be added for blocking. For example, restrict access to certain sections, leaving only viewing.
2. Support for AJAX requests.
   For complete protection, also intercept XMLHttpRequest (header X-Requested-With) and block POST requests sent via AJAX.
3. Rights separation by modules.
   Through the "Rights" tab, you can already selectively prohibit reading of individual modules. You can add a function to automatically hide prohibited menu items.
4. Logging demo admin actions.
   It is useful to log all write attempts to track suspicious activity. To do this, add a cot_log() call in the blocking part.
5. Message customization.
   Replace the standard warning with a more informative one, e.g., indicating the reason and possible actions.
6. Integration with other groups.
   You can create several demo groups with different sets of rights using the same mechanism.
7. Add English language file
   For multilingual sites.
8. Add a setting "Allowed admin sections"
   Instead of full access, implement a whitelist of sections.
9. Move the $dangerousActions list to plugin settings
   So the administrator can easily extend the list of dangerous actions without editing code.
10. Add a hook after creating a demo user
    For example, usersaddsadmin.add.done or a custom hook for additional actions.
11. When creating a user, automatically add them to the Members group
    For more predictable frontend behavior (rights inherited from Members + Demo Admin).
12. Make a banner "You are in demo mode"
    Display a warning in the admin header so the demo user clearly sees the restrictions.
13. Support extra fields when creating a user
    If additional user fields are used, add their processing.

Checklist when finalizing write protection:

• Saving configuration.
• Installing/uninstalling plugins.
• Editing rights.
• Working with structure and page.

7. Conclusions

The User Demo Admin plugin solves the task of providing limited access to the Cotonti admin panel with read-only rights. Thanks to the combination of standard rights (R on all objects, A on the admin panel) and additional blocking of write operations through a global hook, it provides an acceptable level of security for demonstration purposes.

Nevertheless, due to the architectural features of Cotonti (many admin scripts check only the presence of the A right), it is difficult to fully guarantee the impossibility of writing with standard means. Therefore, the plugin should be used with caution and only for trusted users.

If necessary, the plugin can be easily extended by adding additional checks, logging, or integration with other systems. The documentation and code structure allow a developer to quickly adapt it to their needs.