This example demonstrates how to:
authenticateUser
event to perform additional authentication or
authorization of a client before permitting access to a model. Even though a
client can gain access to the Verastream server, you can further restrict
access to a small number of users. This event handler will be called even when
server security (client authentication) is disabled: you can use any method you
like to authenticate clients.
The example uses the modelLoaded
event to create two databases in the
shared model hash map. The first, called authorizations
, looks up
client user names and passwords. Access to the model is permitted only if a
matching user name and password are found. The second, called hostcredentials
,
contains a host user name and password for each client.
The credentials initially provided for in the example are:
|
The example uses the authenticateUser
event to permit or deny access
to the model. If the user can be authenticated, the event handler then checks to
see whether or a different host user name or password should be used. If so, the
user name and password model variables are set to those values before the session
logs in to the host.
A ProcedureEventHandler
uses the executeProcedure
event
to decide whether or not a client has access to a particular procedure. This event
handler is attached to all table procedures which require access checks. Before
the procedure is executed, this event handler compares the name of the procedure
against a set of procedures which this client can call. If the access is permitted,
the event handler uses the doDefaultProcedure
method to call the
procedure and return its results.
Finally, the modelUnloaded
event is used to remove the databases stored
in the shared model hash map when the server unloads the model.
This example uses a variant of the CCSDemo sample model. Event handlers are attached
to the LifeCycle
event source and to each of the procedures.
The event handlers can be called in the Design Tool by first using the Connection Events Test dialog to set the client user name and password, and then using the Procedure Test dialog to invoke the procedures. If you make changes to the password or authorization database, recompile the examples and reload the event handlers to use the new credentials.
Use the Event Handler Preferences dialog's Environment tab to set the
client user name and password which will be used when the Design Tool first
loads the model. If the user name and password are not accepted by the
authenticateUser
event handler, you will be warned that
authentication failed when you first connect to the Host Emulator.
The Connection Events Test dialog is used to enter the client credentials and to simulate clients connecting to and disconnecting from the server. Use the Client user name and Client password controls to enter different client credentials, and then click one of the New Client buttons to simulate logging in to the model as that client. Unrecognized user names or passwords will generate a message stating that the user could not be authorized.
After entering some client credentials, use the Procedure Test dialog to find out which table procedures that client can access. The procedure test dialog already has representative parameter values filled in.
Deploy the Authorization model to the development server. Be sure that server security is turned off unless the user names and passwords used for testing are also recognized by your login authentication system.
Use the Web Builder to create a procedure-based web application. Be sure to select the "Require username and password" option in the web application properties.
Run the web application. Enter some client credentials in the login screen.
If the credentials are not valid (according to the authenticateUser
event handler) client login attempt will be refused. If the login is successful,
access to the different procedures will be allowed only if permitted by
the procedure event handler.