It isn't very difficult.

In the CMS systems I build for work the consist of this basic user
hierarchy:

SUSER = SuperAdmin (admin that can see/do everything)
ADMIN = Admin (admin confined to a specific domain/resource &| duties)
USER  = user (has forum viewing/posting permissions, basic rights...)
GUEST = guest (user that is not authenticated and has limited rights,
usually can only view non-member only content)


I always make a config file for my user hierarchy and give a user
definition a numerical value, ex:

<?xml version="1.0" encoding="UTF-8"?>
<acl>
  <def>
    <user xml:id="SUSER">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <value xml:id="10">SUser</value>
    </user>
    <user xml:id="ADMIN">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <value xml:id="20">Admin</value>
    </user>
    <user xml:id="USER">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <value xml:id="80">User</value>
    </user>
    <user xml:id="GUEST">
      <domains>
        <resource>comprehensible domain for this user type</resource>
        <resource>some other comprehensible domain for type</resource>
      </domains>
      <value xml:id="90">Guest</value>
    </user>
  </def>
</acl>


Above config is just an example, but, you will see how I am defining
each user 'type' with a ID for each user node and a numerical id in the
user->value node to define 'importance'.

I then use the basic ACL classes and config class to load this
definition file into a set of ACL resource and request (you could also
serialize the objects into a database instead of using XML...) objects.

The rules and sometimes assertions are defined in another set of config
files that can be inferred by the values specified in the user type
config file... This makes testing it very easy.

I also usually write an interface class that I load through the
bootstrap that uses a static method to access the ACL methods and my
session class (which is custom but can be applied to Zend_Session too).
This allows me to access ACL and authorize a user based on the values of
the configs.

Util_Auth::check() is all I use in my controllers.

The check method can a number of arguments if you want to override a
specific domain, or action method domain... (say you wanted an entire
controller restricted to users, but a single specific action viewable by
the guests).


Hope this helps you, if not, I might be able to provide simple code
samples to give a more tangible idea of what is happening in a 'basic'
authentication implementation.

Reply via email to