Example: Authentication Using Client/Server Login Dialog

Previous Next

See Also

This example describes a case where a Client/Server startup login dialog is required to authenticates 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.

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( SET_USER,  Variables.Username(),  Variables.Password() )

ActionDecision( StopCatchingErrors)

ActionDecision(GetCaughtErrors)

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

The logic specified in decisions for this example is:

· StartCatchingErrors: This decision tells the Rules Engine not to show errors but to stack them.

SQL: SELECT RulesEngine.StartCatchingErrors('Yes')

Yes/No actions: do-nothing()

· StopCatchingErrors: This decision tells the Rules Engine to revert to normal error handling.

SQL: SELECT RulesEngine.StopCatchingErrors()

Yes/No actions: do-nothing()

· SET_USER: This decision tells the Rules Engine to start working for the specified user in the first argument of the SetUser method.

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

Yes action: dialog-ok()

No action: Variables.Password(''); Variables.Username.Text_Box.ControlSetFocus()

· GetCaughtErrors: This decision reports all errors stacked between the start/stop catching error directives. This is where errors might be filtered or replaced by other texts to avoid echoing password information to the screen. The caught error content depends on the Validation Agent that applies for a particular user.

SQL: SELECT RulesEngine.GetLastCaughtErrors()

Yes action: MessageInformation(:1)

No action: do-nothing()

4. 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.

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