osCommerce User Management

osCommerce is one of the oldest open-source e-commerce platforms (dating to 2000), and its user management reflects that era. The core platform has a minimal admin permission system -- in the classic osCommerce 2.x line, there is essentially a single admin account with full access. osCommerce Online Merchant 4.x (Phoenix/CE community editions) introduced basic admin group support, but it remains far simpler than modern platforms.

Permission model

osCommerce's permission model depends on which version you run:

osCommerce 2.3.x (classic):

• Single-tier admin access. All admin accounts created in administrators table have full back-office access.
• No role-based permissions, no route restrictions, no ACL.
• Access control is binary: you either have admin access or you do not.
• File-level security (.htaccess, .htpasswd) is the primary mechanism for restricting access to /admin/ directories.

osCommerce CE / Phoenix (community editions):

• Added basic admin groups with module-level access control.
• Admin groups can be restricted to specific admin modules (Catalog, Orders, Customers, Reports, Tools, Configuration).
• Permissions checked per admin page load -- if the admin's group lacks access to a module, the menu item is hidden and direct URL access is denied.

Storefront customers:

• Standard registration with email/password.
• No customer groups or tiered access in core. All registered customers have identical storefront capabilities.
• Add-ons like "Customer Groups" contrib modules can add pricing tiers but not permission differentiation.

Available roles

There is no built-in Super Admin vs. Admin distinction in 2.3.x. Every entry in the administrators table is equivalent.

Admin UI paths

API access management

osCommerce does not ship with a REST API. Integration options:

• Direct database access -- most integrations read/write to MySQL tables (orders, products, customers) directly. Secure via MySQL user grants scoped to specific tables.
• Contrib modules -- community-contributed API modules (e.g., osC_API, REST API add-ons) add endpoint access. These typically use API keys stored in the configuration table.
• XML export/import -- some integrations use file-based data exchange in /export/ directories. Protect with .htaccess and filesystem permissions.
• Action Recorder -- osCommerce 2.3.4+ includes an Action Recorder module that logs admin actions and can enforce rate limits. Configure at Configuration > Action Recorder.

Since there is no native API authentication framework, any service-to-service integration relies on database credentials or custom module tokens. Document all integration accounts and rotate MySQL passwords on a schedule.

Analytics-specific permissions

osCommerce's analytics capabilities are limited and extension-dependent:

• Built-in reports -- basic sales reports at Reports > [Products/Orders/Customers]. In classic 2.3.x, any admin can view all reports. In CE, restrict by denying the Reports module to a group.
• Google Analytics -- typically added by editing /includes/header.php or /includes/footer.php to insert the tracking snippet. Any admin with file access (FTP/SFTP or file manager add-on) can modify tracking code.
• Header Tags module -- community modules like "Header Tags SEO" allow inserting scripts via admin configuration instead of file edits. Access follows the Configuration module permission in CE.
• Order tracking pixels -- conversion tracking on the checkout success page (checkout_success.php) requires direct file editing. No admin UI for this in core.

To protect analytics configurations:

1. Place tracking code in a dedicated include file (e.g., /includes/analytics.php) and restrict SFTP access to that directory:

<?php
// /includes/analytics.php -- centralized tracking code
// Only edit this file via SFTP; restrict access to analytics team
?>
<!-- Google Analytics 4 -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXX');
</script>
<?php
// Include in header.php with: require_once(DIR_WS_INCLUDES . 'analytics.php');
?>

2. In CE/Phoenix, create an admin group for marketing with access only to Reports and Configuration modules.
3. Use the Action Recorder to audit who accesses admin pages that could affect tracking.
4. Since osCommerce lacks granular permissions, consider .htaccess rules to restrict specific admin pages to certain IP addresses.