Login- A good example of customizing the dynamic model

With the Dynamic Data Model rewritten in the new routing format, it was relatively easy to get the Login roles working. The next step is to make the ACL work. The login system is implemented in 3 different pieces:

• The Users object
• The rLoginIdentifier roles
• The UsersLoginCtx context

Each of these pieces serves a different purpose, explained below.

The Users Object

The Users object contains the basic object that extends DDM. Additionally, it implements the rLoginIdentifier which provides the Authenticate() and session management methods. This object also provides the target for the actual request-- as in the URL for accessing the login function is:

/Users/login

rLoginIdentifier

The rLoginIdentifier role provides methods that Authenticate the user against the dynamic model. It makes use of the PasswordAttribute class and the rPasswordHasher role to hash the password using a User-specified hash function. The LoginIdentifier role also provides access to 2 session management methods:

• SetSession($var, $value)
• DestroySession()

Where SetSession can set and unset session variables, while DestroySession can destroy a session for logout purposes.

UsersLoginCtx

This is the class that actually handles the Login request. Requests are handled either by a corresponding context name (ie: UsersLoginCtx) or role method (Users->Login). In this case, the context is used since each application's Login method will be different and as such, should not be coded as a role method. Since the Authenticate role only returns the result of the actual Authentication, this context is responsible for handling the result of the Authenticate function. It takes the result and stores it in the session, then redirects the User to the home page. This context must be coded specifically for each application. It allows for the basic Authentication module to be very dynamic (providing a list of different hash functions), while allowing the actual session management to be completely custom.

More To Come...

This is just this first example of the model of programming that Wax and the IWH package are built on. The roles will provide commonly used functionality (scaffolding, the dynamic data model, login/sessions, etc.), while the contexts provide a way to set up these function calls around custom application functionality.