A web application requires a session manager object. Typically this is used to create a unique session key that is passed back and forth between server and client. This is used to maintain application state and to provide a secure mechanism for storing information on the server that should not be changed or even seen on the client. An example of this of this would be login names and user rights.
At the lowest level the session manager object must adhere to a simple interface. As long as the interface is provided the implementation can be written any way you want. We also provide a higher level implementation that provides a mechanism for starting a session, logging in and assigning user level rights. This is probably the level where most developers will want to start and that is what is described here.
A Web application must contain a single session manager object. Its object handle must be stored in the ghoSessionManager global variable. All communications to the session manager should be made via this variable.
When a browser starts a web application, the Web application will know that it needs a session key and it will send CreateSession to the session manager. The session manager will create a unique Session Key. If session logging is enabled (and it usually is – see the cWebApp pbLogWebSession property), a session record will be logged in the WebAppSession table. CreateSession returns this session key and this is what will be sent back and forth between client and server.
When a standard login dialog is created, it sets the cWebApp phoLoginView property. If a login is required (see the cWebApp peLoginMode property) and there is a login dialog handle in phoLoginView, that login dialog will be shown and the user can login in. The login dialog attempts to verify the login by sending UserLogin to the session manager. It passes the login name and password and is returned a Boolean indicating the status of the attempt.
UserLogin in the session manager performs the login. It looks up the user name in the WebAppUser table and verifies the password. Our standard login record also contains a user rights column, which can be used to determine access rights. If the login is successful, this user information is stored in the newly created session record.
When a Web application is loaded, NotifyChangeRights is sent to the session manager. By default the session manager uses this to update the menu and tool bar system allowing you to enable, disable or hide items based on user rights. It also sends OnChangeRights to the cWebApp object, which can be used for custom purposes. NotifyRightsChange should be sent to the session manager object each time a different user logs into your application. Our standard session manager object’s UserLogin implementation will do this for you.
From this point on, every request is passed the session key from the client. The server request starts by calling the session manager’s ValidateSession method passing the session key. The session key is used to find the session record in the WebAppSession table. As noted, that record contains information about the session and the user (name, user-rights, etc.). This is used to determine what is allowed for this request.
The OnSyncView event is sent to the active view for every client request. This can be used by your security rights management system to set various rights and roles constraints properties in the view during the AJAX call, before the call is executed.
The AllowViewAccess message is sent to the active view (or in the case of modal dialogs, the dialog and its invoking view). This is used to determine if the user has the rights to access this view at all. It can also be used to customize the view for a particular access level. If it returns False then the client request will not be processed.
Through processing of the request the session manager’s piUserRights, psUserName and psLoginName can be accessed to determine how processing should proceed.
The session manager methods RequestLogin and RequestLogout can be called to perform a login/logout at any time. NotifyChangeRights is also sent each time a user logs in.
The cWebApp object supports properties that allow one to quickly manipulate the login logic.
Property peLoginMode (lmLoginRequired, lmLoginSupported, lmLoginNone)
You can have three login modes. If lmRequired, your application needs to login and upon loading a Web application the login dialog is invoked and you must login to proceed. If lmSupported you don't need to login but you can choose to login if you have code that needs extra rights. If lmNone, there is no login system being used at all.
The login dialog is defined in phoLoginView. By default our LoginDialog.wo sets phoLoginView. So adding this .wo, adds the login dialog and sets the property.
This determines if the session manager object should log sessions in the session data-file. With our current session manager, you can only set this to False if peLoginMode is set to lmLoginNone because our login logic requires saving session records. It is conceivable that some other session manager would not have this requirement, which is why this is not just another peLoginMode mode (lmLoginNoneLogNone).
The cAjax WebApp object is sent OnLoad before it performs the determination that a login is actually required. This allows one to easily perform a login manually, which could be handy for testing at various rights levels.
Procedure OnLoad
Boolean bOk
Get UserLogin of ghoWebSessionManager "john" "John" to bOk
End_Procedure
If you don’t want the menu system to be visible during login you can hide the command bar system when you are not logged in. Each time user rights change, the event OnChangeRights is sent to the main cWebApp object. OnChangeRights is also sent to the commandbar object and to every object within the command bar system. OnChangeRights is also sent when an application first loads. Therefore we can augment OnChangeRights in the command bar object and hide it as needed.
Object oCommandbar is a cWebCommandBar
Procedure OnChangeRights
Boolean bLoggedIn
Get IsLoggedIn of ghoWebSessionManager to bLoggedIn
WebSet pbRender to bLoggedIn
End_Procedure
We use the session manager’s IsLoggedIn function to determine if you are logged in. As soon as you log in, OnChangeRights will be called again and the entire menu/toolbar system will become visible.
You can use similar techniques to enable or hide toolbars or individual items. You can also use this technique based on the user’s rights level as opposed to being logged in or not.
The previous section described how default session management works when using our standard session manager (SessionManager.wo), our standard login dialog (LoginDialog.wo), our standard session table (WebAppSession) and our standard user table (WebAppUser). You can extend any or all of these yourselves by creating your own replacement versions of any or all of these components. You will probably do this by using our classes and objects as examples and building replacement tables, replacement objects, or sub-classes. At the most abstract level, you will need to support the following interface in your session manager.
AllowViewAccess
CreateSession
EndSession
IsLoggedIn
NotifyChangeRights
RequestLogin
RequestLogout
UserLogin
ValidateSession
In addition, the global variable ghoSessionManager must contain the handle of the session manager.
As an example, you could choose to replace the default session manager with our cWebSessionManager base class by changing the code in WebApp.src as follows:
// Use SessionManager.wo // don't use our standard session manager
// Use LoginDialog.wo // don't need a login dialog at all
// now create this simple session manager instead.
Object oSessionManager is a cWebSessionManager
End_Object
This provides the most basic session manager, which provides and validates a session key. The login dialog, the session table and user table are not needed. This class supports the session manager interface at the simplest level.
Previous Topic: Search Dialogs in Prompt Lists
Next Topic: Enhanced Security in Web Framework Applications