BEE Script:   access (accessControlSpec) statement;

            [else statement;]

or          access [(accessControlSpec)] { statement; ... }

            [else { statement; ... }]

BEE Tag:     <beeaccess [accessControlSpec]>

                  tag

                  ...

            [<beeelse>

                  tag

                  ...]

            </beeaccess>

Note: The accessControlSpec is surrounded by a small bracket and therefore is taken literally.  So please do not quota it with double or single quote or the quotation marks will be taken literally as part of the value.

Example 1:

access display 'Hello {sys%auth:username}';

else display 'Please login first';

Example 2:

access (admin) {

      // ... display the logout button here

      display 'Go to <a href=/admin>Admin Site</a>';

} else {  // Not admin user

      access (at most public) {

            display 'Please login first';

            // ... display the login form here

      } else {  // higher than public

            access (@friendly.site.com) display 'Hi Pal';

            else {

// Stop if it is user "john" of realm "myown.site.com"

                  access (john@myown.site.com) exit;

                  else display 'Welcome my dear member';

            }

      }

}

The "access" command defines a block that is executed only when the current session matches the accessControlSpecification (ACS) enclosed in the small bracket.

There are various authentication settings that you can select when your site is established, such as the password encryption scheme, the location and access method of the user table and how to map the information on that table.

The concept of "realm" (a group of users who share the same name space) is built into the BEE platform and implemented in CROFT.  You can use a field in the user table to indicate the realm (e.g. the Department field of the Staff table), or you can have physically separated tables for different realms.

For example, you can allow the sales staff of a branch office in Melbourne to login via a realm called "melsales".  When someone logs in using, say, "matthew@melsales", CROFT will check the Auth table at the Melbourne branch server to verify the password for "matthew".  You can use the "access" command to grant/restrict access of such "affiliate" member.

The "Auth" table can locate at any server as long as the BEE server where your web page is running from have access to the "Auth" table via the Internet.  This allows the end user to run their own authentication system in house (or in any facilities they choose).

The "Auth" table can in fact be a scheme File.  For example, if you establish the web site authentication with @itguys realm pointing to the "staff" scheme file and have

john:Password=abc

john:AccessLevel=2

john:Name=John Lee

then "john@itguys" can login with password "abc" and gain member access.  In fact, you may have more than one realms in the same authentication scheme file.  For example:

mary@marketing:Password=def

mary@marketing:AccessLevel=2

mary@marketing:Name=Mary Young

Of course, you will need to establish the realm @marketing to point to the "staff" scheme file as well.  However, extra care is needed in this case.  If no realm is specified in the login, only entries without realm will match.  If a realm is specified, entries with the specified realm will be searched first, and if there is no match, entries without realm will be searched.  In the above example, "mary" (without realm in the login) will get no match, while "john@marketing" and "john@marketing" will both match the entry "john".

It is recommended to use separate authentication scheme files for different realms to avoid confusion.  In such case, there is no need to put realm specification in the entries.

For flexibility in integration, the Auth table can have any attributes of any arbitrarily names.  All attributes is accessible via the sys%auth:attribute variable.  CROFT recognises six attributes in order to operate the authentication process.  Three CROFT attributes are for user identification: Username, Password and Realm.  There are another three for session control: Access Level, Active and Expiry.  CROFT requires at least the Username and Password.  All the other four can be omitted in the Auth table without affecting CROFT.

·         If Realm is omitted from the Auth table, CROFT will take the whole table to be from a single pre-defined realm (usually blank).  If any of the three session control attributes are omitted, a default value needs to be entered into CROFT.  For example, #2 for Access Level if all users in the Auth table has Member access; #1 for Active if all are active; and #0 for Expiry if none will expire.

User Identification Attributes:

Username: login user ID

Password: password (encrypted with a scheme chosen at set up time)

Realm: an optional suffix following the user ID (ie user@realm) for user grouping and access control

Session Control Attributes:

Accesslevel: access privilege (a common name mapping is public=0, affiliate=1, member=2, vip=3, owner=8, admin=10)

Active: whether the user record is effective (non-zero means active)

Expiry: timestamp indicating when the user record is deactivated (0 means never)

Parameters

access specifies the ACS (Access Control Specification).  Default is "higher than public".

The ACS comes in two different forms:

Form 1:            [relation][accessLevel]

Specifies a range of access level at which the user can access the controlled block that follows.

relation is default to ">=". accessLevel can be the access level number as well.  The default is "member".

Here're some examples:

higher than affiliate
at least vip
over 2

Common expression can be used to a certain extend.  The followings are valid relational words:

less than
below
under
greater than
above
over
equal to
same as
at least
at most
not ...
lt
le
eq
ne
ge
gt

All these will be translated to the proper mathematical symbol.  e.g. less than is < and at least is >= etc.

Form 2:            [user]@[realm]

Specifies a user or a group of users who can access the controlled block that follows.  The "@" sign is compulsory (even if the web site do not use the "realm" feature).  If user is missing, it means all users in the realm.  If realm is missing, it means the "blank" realm.

Here're some examples:

@marketing            All users in realm "marketing"
john@               User "john" in the blank realm
mary@billing            User "mary" in the realm "billing"

In particular, "not" means to exclude the user or group of users from accessing.  e.g. "not @staff" means NOT in the realm "staff".

After the "if" command is executed, the following BEE Variables are made available: