Novell Home

AppNote: Building Blocks for SecureLogin Scripting

Novell Cool Solutions: AppNote
By David Guest

Digg This - Slashdot This

Posted: 29 Jul 2004
 

David Guest
Consultant
dguest@novell.com

Executive Summary

This document puts forward a standard approach to scripting applications within the Novell SecureLogin (NSL) environment. It explains the building blocks that must be included within the scripts for Windows, Web, and Terminal Emulation applications.

This document does not

  • Describe the scripting process
  • Describe the commands used within scripting
  • Attempt to present a training environment for support staff who wish to learn how to script and support the existing scripts

Formatting Notes:
Indenting within the scripts is good practice, mainly so it is cleaner to read.
Some of the lines within the script are longer than a standard page width and these lines have wrapped. If they were copied verbatim then they may give errors.

Building Blocks

Each NSL script should contain a number of sections, or building blocks. When combined, the building blocks produce a valid and complete script. They should be easily identifiable and, where possible, have additional comments built in to the script to simplify the support of the scripts.

A script should contain the following building blocks:

Script Header
Log In Dialog
Change Password Dialog
Password Expiration
Log In Failure
Log in success (Mostly in Terminal Emulation)
Other Message Detection

Script Header

At the start of each script, use a standard header. This header includes details on the application being scripted, modification dates, and the modifications made. A standard header would look as follows:

#############################################
#
# Secure Login Script
#
# Application : 
#
# Application Description : 
#
#
# Initial Script created on : 
#                        by : 
#
#############################################
#
# Modification Log
#
# Modified By - Date (yyyymmdd) - Description
#
# e.g. David Guest - 20040302 - Initial Script Creation
#
#############################################

By cutting and pasting, insert this header at the start of each script.

Log In Dialog

The heart of the single sign-on process is the auto-completion of the Log In dialog box. NSL works by detecting the authentication request (window) of the application and responds specifically to each window.

The following screen shot shows a typical authentication dialog box:

This dialog box requires data in the Username, Password, and Other Field edit boxes (fields). NSL detects this window and responds appropriately. The script excerpt that handles the fields in this window is as follows.

Dialog
  Class "#32770"
  Title "Log in"
EndDialog
Setprompt "Username:"
Type $Username #1001
Setprompt "Password:"
Type $Password #1002
Setprompt "Optional:"
Type $Optional #1003
Click #1

The script specifies the class and title of the window, with the correct details being entered into each field.

Change Password Dialog

Obviously, any change to the user password within an application must be managed. This is accomplished by monitoring the application to detect the display of the change password dialog. A sample change password dialog could be:

In this dialog box, the application is asking for the old password to be inserted before the new password is entered and confirmed.

To manage occasions where the password change fails (possibly because a password is not complex enough or it has been used before), NSL must store the old password until such time as the password change is confirmed.

This dialog box is managed by the following script excerpt:

Dialog   
   Class "#32770"   
   Title "Change Password"
EndDialog
Setprompt "Username:"
Type "$Username" #1015\
Setprompt "Password:"
Type "$password" #1004
ChangePassword ?newpassword
Type ?newpassword #1005
Type ?newpassword #1006
Click #1
If ?changePasswordDelayCommit(PasswordTest.exe) eq 0
   Set $password ?newpassword
EndIf

Password Expiration

As passwords expire, many applications prompt the user with details that show the password has expired. This prompt might take the following forms:

  • A single message box with both the expiry message and the fields for the updated passwords


  • Two dialog boxes, the first advising of the password change requirement and the second allowing the user to change the password

The routing to change the password should be identical to the change password section above.

Login Failure

When a user fails to access the application because either an ID or password is incorrect, NSL must recognize the failure and react accordingly. Some applications produce a separate dialog box with a message similar to "Your Login Attempt has Failed". NSL must intercept this dialog box and prompt the user to change the ID or Password. This process might look like the following script excerpt.

Dialog
  Class "#32770"
  Title "Logon Failure"
EndDialog

DisplayVariables "Your login attempt has failed. Please confirm your 
Username and Password." $Username $Password
Click #2

When the control passes back to the login screen, the login section should be repeated. It is always worth incrementing a counter to ensure that the user does not get stuck in a loop by putting in what they believe is the correct details when the application will not accept them. You can prevent the loop by adding the counter to the failure dialogue.

Dialog
   Class "#32770"
   Title "Logon Failure"
EndDialog
Increment ?FailCount
If ?FailCount lt 3
   DisplayVariables "Your logon attempt has failed. Please confirm your 
Username and Password." $Username $Password
   Click #2
Else
   MessageBox "The Username and password are still incorrect. Please contact
   the help desk for more details."
      KillApp "AppTester.exe"
   EndScript
EndIf

This excerpt also closes down the application which is running after asking the user to contact the help desk.

Login Success (Mostly in Terminal Emulation)

In some cases, mostly where repeat/endrepeat loops are used, it is necessary to detect the success of a login and break out of the script.

Specifically, terminal emulation scripts work in this manner. With Windows scripts, the script runs repeatedly and activates only when a recognized dialog section appears. With Emulation, this is not the case--the script starts at the top and runs to the end.

With Generic and Advanced Generic emulators, it is necessary to read the complete screen of information, looking for specific text. This process might cause the screen to flash as the text is selected and copied. This text is searched through to match any text being searched for. This flashing can make the screen unusable for a user and generally means that the script must have finished before a user can use the system.

To search multiple screens, it is necessary to start a repeat section that looks for specific text, and then act on that text at each point. When the final "User is logged on" text appears, the script should be ended.

Other Message Detection

Often whan an application is running there will be additional messages that appear on the screen that are meaningless to the user, or that relate to password changes but are not critical to the operation of NSL. These tow must be catered for. As an example some applciations advise on the forthcoming expiry of the password. This could take the form of a message box stating "Your password will expire in 5 days." and allowing the user to click on OK only. This message can be trapped by NSL and the "OK" button hit on behalf of the user.

Often this sort of message takes the form of a standard information dialogue with different text depending on the messag erequired. This can be handled by the following script excerpt.

Dialog
   Class "#32770"
   Title "Information"
EndDialog
ReadText #65535 ?Message
If ?Message eq "Welcome to the application"
   Click #1
EndIf
If "Your password will expire in" -In ?Message
   Click #2
Endif
If "The system is going down for maintenance in 5 minutes"
   MessageBox "Watch out the system is going down very soon"
EndIf  

Summary

Using these building blocks should enable scripts to be built that can cope with many of the common scenarios produced by applications. Although these uidelines can help, there is no replacement for experience or practice. Don't be afraid to try something new in a script, quite often these new ideas work very well and can lead on to new avenues for the use of Secure Login.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell