Member Avatar for Webville312

Dear all,

I have a challenge here of understanding the page masks as used in this code;

<?
    $access_level_map['loader']     = 1;
    $access_level_map['support']    = 3;
    $access_level_map['admin']      = 7;
    $access_level_map['superadmin'] = 15;

    define("LOAD_PAGE_MASK",1);
    define("SUPPORT_PAGE_MASK",2);
    define("ADMIN_PAGE_MASK",4);
    define("SUPER_ADMIN_PAGE_MASK",8);

    $pageMaskMap['add_employee.php'] = SUPPORT_PAGE_MASK;

    $pageMaskMap['awpdc.php'] = SUPPORT_PAGE_MASK;
    $pageMaskMap['awpdc_blocked.php'] = SUPPORT_PAGE_MASK;
    $pageMaskMap['awpdc_unblocked.php'] = SUPPORT_PAGE_MASK;

?>

What I know is that this page controls which user can access what page. However, I have been tasked to add another user to this mask, and I have no idea on how to go about this one.
Any help will be greatly appreciated.

Thanx

Edited by Webville312 because: Had to make the heading unambigous
  • 2 Contributors
  • 4 Replies
  • 180 Views
  • 3 Hours Discussion Span
  • Latest Post Latest Post by Webville312

Dani AI

Generated

This is a classic bitmask ACL — page masks are single-bit flags and each user’s stored access value is a combination (bitwise OR) of those flags. already pointed out the important bitwise-AND check; that is the right mechanism to decide access. ’s idea of adding a new role is on the right track, but a couple of practical tips will make it safer and easier to maintain.

Keep flags explicit and avoid “magic” cumulative numbers sprinkled through code. Define each role as a single-bit constant (powers of two) and build a user’s access value by OR-ing role flags. Put the flag constants in one include file so every page and admin tool uses the same names. When adding a new role:

  • pick the next unused bit (the next power-of-two),
  • add the new constant to your central include,
  • give manager accounts that flag in the database (or update your role-assignment UI to set it),
  • update any page->mask mapping that should require the new flag,
  • test both allowed and denied cases.

A small, maintainable pattern to follow (use in a common include) is to define flags and a single helper that encapsulates the check. That keeps permission logic in one place and avoids accidental numeric comparisons like >= which break with bit flags.

Common pitfalls: mixing two schemes (sequential access-level numbers vs independent flags), forgetting to update all pages/includes, and using loose truthiness instead of a strict nonzero comparison when checking bits. If your application will grow to many roles/permissions, consider a simple role->permission table in the DB instead of relying solely on bit arithmetic — it’s easier to audit and extend.

Recommended Answers

All 4 Replies

Member Avatar for Member #120589

support and above users can view those.

You can check if the current user has permission to view the pages with a bitwise operator:

if($myAccessLevel & $thisPageMask)
{
    //Allow entry
}else{
    //header away
}

For example if my accesslevel was support (3) and the pagemask was load (1), then because 3 and 1 have a common "1 bit": 11 and 01 - they match.

Other examples:

loader 1 (1)
support 11 (3)
admin 111 (7)
superadmin 1111 (15)

loaderMask 1 (1)
supportMask 10 (2)
adminMask 100 (4)
superadminMask 1000 (8)

So when you compare and get matched bits, you allow access to the page. E.g.

superadmin 1111 and superadminMask 1000 but not

admin 111 and superadminMask 1000

Member Avatar for Webville312

Aaaah, I get it now; So that means that if I add another user, say a Manager, then I'd do something like;

$access_level_map['loader'] = 1;
$access_level_map['support'] = 3;
$access_level_map['admin'] = 7;
$access_level_map['superadmin'] = 15;
$access_level_map['manager'] = 31;

define("LOAD_PAGE_MASK",1);
define("SUPPORT_PAGE_MASK",2);
define("ADMIN_PAGE_MASK",4);
define("SUPER_ADMIN_PAGE_MASK",8);
define("MANAGER_PAGE_MASK",16);

Is that correct???

Member Avatar for Member #120589

Yep!

Member Avatar for Webville312

Awesome, Thanx a bunch.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.