Example: Client/server login dialog

This example describes a case where a Client/Server startup login dialog is required to authenticate the USoft application user. In this example, the user is a funneling account that only exists in USoft; there is no database account for that user. The USoft application uses a single RDBMS funnel account to serve all its funneling users.

1.	User starts USoft application from USoft Binder. The RDBMS account that is to be used as a funnel account is specified in USoft Binder, using the Project properties option from the File menu, and choosing the Database tab.

2.	A modal Login dialog with a user name and a password field is presented by the application . The user name field contains the operating system user name as a default. For example:

This login dialog is the result of specifying a WindowsCreate action in the Windows Designer, when defining this application, for example:

WindowCreate(My Login Dialog)

This action is specified in the Windows Designer using the Edit Application option from the File menu, the choosing the Behavior tab from the Application Properties option.

The default username is retrieved using:

RulesEngine.GetProperty('OSUSERNAME')

The assignment takes place on the Username field, in the behavior tab Post-create property specified as:

Variables.Username(RulesEngine.GetProperty('OSUSERNAME'))

3.	The user modifies the user name (optional) and specifies a password (optional), then clicks the OK button.

The action on the OK button executes the Rules Engine SetUser method but avoids readable password echoes by making sure that error messages are not generated:

ActionDecision( StartCatchingErrors )

ActionDecision( SetUser, Variables.Username(), Variables.Password() )

ActionDecision( StopCatchingErrors )

ActionDecision( GetLastCaughtErrors )

If the user name does not exist or is not associated with the application, a message is shown about the credentials being invalid.

4.	Define the StartCatchingErrors decision. This decision tells the Rules Engine not to show errors but to stack them.

Set Decision SQL to:

SELECT RulesEngine.StartCatchingErrors('Yes')

Set both Yes Action and No Action to:

ActionDoNothing()

5.	Define the SetUser decision. This decision tells the Rules Engine to start working for the specified user in the first argument of the SetUser method.

Set Decision SQL to:

SELECT RulesEngine.SetUser(':1', ':2', '')

Set both Yes Action and No Action to:

ActionDoNothing()

6.	Define the StopCatchingErrors decision. This decision tells the Rules Engine to revert to normal error handling.

Set Decision SQL to:

SELECT RulesEngine.StopCatchingErrors()

Set both Yes Action and No Action to:

ActionDoNothing()

7.	Define the GetLastCaughtErrors decision. This decision tells the Rules Engine to revert to normal error handling.

Set Decision SQL to:

SELECT RulesEngine.GetLastCaughtErrors()

Set Yes Action to:

MessageInformation( :1 )

Set No Action to:

ActionDoNothing()

8.	If the validation agent associated with the USoft user name accepts the specified password, the login dialog window is closed, the application menu can be accessed and the application works with the application access rights as specified in the USoft Authorizer for the USoft user account.

If the user group changes, the application property "After Usergroup Changed" fires. This allows user group-specific actions like opening a window or catalog.

If the user group changes, the First Menu Page specified for the new user group become active.

The After SetUser behavior property fires. This allows user-specific actions to be programmed.

9.	If the validation agent does not accept the password, a message is shown stating that credentials are invalid.