Webcrossing "out of the box" already gives you a fair amount of flexibility to control the login and registration processes. You can choose to allow new users to register without any intervention. You can turn that feature off so that new users can only be registered by a sysadmin. You can set the registration process to include a validation email to ensure that new users provide a working email address, and you can restrict user privileges until the validation process is completed.
You can set the login process to be handled by the standard web form. You can also allow login via the HTTP basic authentication protocol. Webcrossing also supports validating login credentials with an external RADIUS, CalNet, or LDAP server.
And if all of that still does not meet your needs exactly, Webcrossing provides a handful of filters to modify the registration and login processes. They are:
registerProcessFilter
registerFailureFilter
loginFilter
loginFailureFilter
All four of these filters manage the process by returning one of the following formats in the response buffer:
- An empty string to continue with normal processing. This is as if the filter was not present at all. If working in WCTL it's usually wise to use the %% clearOutput %% directive to make sure the buffer is empty.
- A fully-formatted page of HTML that begins with either <html> or HTTP. (If the latter, you must create all the HTTP headers yourself rather than letting the system supply them. You can use this feature to redirect the user to another page or site.) The page is returned to the user immediately with no further processing.
- A WCTL userID. If the filter evaluates to a user ID, this user becomes the current user. Webcrossing creates an authentication certificate and/or cookies depending on site settings and they are available in subsequent page requests.
- for the registration filters only, any other output (such as an HTML or text snippet) will be treated as an error message; the registration form will be redisplayed with this output as a message.
registerProcessFilter fires after a registration form is submitted but before any other processing. The current user inside the filter will always be userIsUnknown or, if the sysadmin is registering another user, userIsSysop.
registerFailureFilter is called after processing a registration form when the registration failed for any reason.
loginFilter fires after a successful login, but before processing the login's actionPath (that is, before redirecting to the original requested page if the login page was interposed). The current user is available; the original request including the query string and any cookies can be accessed by using the envir pseudo-object in WCTL or the request object in SSJS.
Finally, loginFailureFilter fires after a failed login. If the form submitted contained a valid user name but an incorrect password, the user object is set. As with loginFilter the original request is available, and the contents of the username and password form fields can be recovered from the form object.
No comments:
Post a Comment