A few important things here. Notice that we can register the variable
before it exists. This is perfectly valid, as long as the variable we are
registering is defined before the end of the script. You'll also notice
that we did not simply store the variable passed by the form. For security
reasons, you should never blindly store form data. As shown above,
you should always check the form variable to make sure it is what you
expect (in this example a user function "check" was used to do this).
Finally, if the data checks out to be okay, then you copy it to
your registered variable.
After registering the variable, it is written to the database by the
page_close() call. If you forget your page_close() call, your session data
will not be saved, giving you some possible surprising results. On
subsequent pages, the page_open() call will restore the session variables
out of the database. In the example above, the registered variable $first
will be available as $first automatically. If you no longer need them, session
variables can also be deleted by calling
With PHPLIB 6.1 (the current release), session data must be stored in a
database. With the upcoming 7.0 release, PHPLIB uses a storage container
mechanism, which allows you to store it in a database, shared memory, or
even LDAP. PHPLIB uses a database class which makes your choice of which
database arbitrary, we'll see more on that later.
Permissions tie in closely with authentication. Once a user is
authenticated, you can then have the option of checking their permissions
to prevent them from accessing certain data. To do this, you must set up
your permissions class in the page_open call. There are two main functions
to check permissions.
This function will check to see that the user has the permission level you
specify. The permission levels are defined in your local setup ( in the
local.inc file ) and thus can be anything you like. For the check function,
if the user does not have the permission level specified, the function
perm_invalid() is automatically called. You may create your own
perm_invalid function, or use the specified on which simply reports that
the person does not have appropriate permissions, and then exits.