Handling Emulators with SecureLogin

Novell Cool Solutions: Feature
By David Guest

Digg This - Slashdot This Posted: 4 Nov 2005

SecureLogin provides the ability to interact with Windows, Web, and Terminal Emulation applications. While the Windows applications are more or less straightforward, there is little information on how to handle applications using the various emulators.

This document will provide an approach to developing the script and handling the issues that are faced with the various emulator types.

Emulator Types

There are four types of emulator that can be used with SecureLogin:

• Generic
• Advanced Generic
• HLLAPI (High Level Language Application Programming Interface)
• DDE (Dynamic Data Exchange)

These can be put into two different groups, which are handled differently by the script. The first type of emulators is the Generic and Advanced Generic emulator. These use screen-scraping technology to determine what is being displayed on the emulator screen. The other group of emulators is HLLAPI and DDE; here, the script can interact more specifically with the emulation screen and can be much more specific with the actions it performs.

Screen Scrape - Generic Emulators

Using Screen Scraping presents a number of issues with the behavior of the script and the emulator. The screen scrape uses a "Select All + Copy" function to place all of the screen data into the buffer which SecureLogin reads.

If you have ever used a word processor and done a "Select All" you will have seen that the complete document is inverted - instead of black on white, the image on the screen becomes white on black. The same behavior occurs when the emulator is running. Each time the script performs a ReadText or a WaitForText, the screen inverts. This produces a blink on the emulator screen. While this is necessary for the script to function, it is not pleasant for the user.

To get around this, the SplashScreen commands (BeginSplashScreen and EndSplashScreen) are used. This means that the script must finish and have the SplashScreen removed before the user can interact with the application.

To write a script for this, it is necessary to determine all of the messages that can be seen before the actual application starts, as well as some necessary information from the initial page of the application. A loop is employed to ensure the handling of all the screen information, up to the point when the application itself starts.

The problem here is that if the user has a menu option that allows a change of password, SecureLogin will not be able to "see" the change and remember the password.

Looking at a sample script shows all of the features of a standard Emulator script. The normal script that is used is very simplistic:

WaitForText "ogin:"
Type $Username
Type @E
WaitForText "assword:"
Type $Password
Type @E

Here we look for the text "ogin" on the screen and then put the Username in, then wait for "assword:" and insert the Password.

As an aside - one of the questions that is often asked is why is it "ogin:" and not "Login:"? The reason for this comes back to the use of Generic emulators. What we are doing is screen-scrape based, in many cases, using an offset that tells SecureLogin where on the emulator window to start to do the scraping. It is very easy to get this wrong (or even to use a different resolution) and to miss part, or all, of the screen. By using the short form of the word we are assuring that SecureLogin can "see" and react to it.

A more complex script for an emulator would be this:

WaitForText ?ogin:?
Type $Username
Type @E
WaitForText ?assword:?
Type $Password
Type @E
Repeat
# Check for failed login
Increment ?ScreenCount
If ?ScreenCount eq 1
 If -Text "ogin incorrect"
  Increment ?RunCount
  if ?RunCount eq 1
    DisplayVariables "Please re-enter your ID and Password?
    Type $Username
    Type @E
    Delay 500
    WaitForText "assword:"
    Type $Password
    Type @E
  Endif
 EndIf
 #Check for password expiry
 If -Text "New Password:"
  If ?PasswordChange eq <notset>
    Set ?PasswordChange 1
    ChangePassword ?NewPassword "Your password must be changed."
    Type ?NewPassword
    Type @E
  Endif
 Endif
EndIf
If ?PasswordChange eq 1
  If -Text "e-enter new Password:"
      Type ?NewPassword
      Type @E
    Endif
  Endif
  If -Text "Press RETURN key to continue ..."
    Type @E
  Endif
  If -Text "MENU"
    EndSplashScreen
    if ?PasswordChange eq 1
      Set $Password ?NewPassword
      Set ?NewPassword <notset>
    endif
    Set ?PasswordChange <notset>
    Set ?ScreenCount <notset>
    break
  endif
  EndRepeat
  EndSplashScreen
  if ?PasswordChange eq 1
    Set $Password ?NewPassword
    Set ?NewPassword <notset>
  endif
  Set ?PasswordChange <notset>
  Set ?ScreenCount <notset>
  break
endif
EndRepeat

This script looks for a lot of information coming from the emulator. Closer examination of the script shows that it starts with normal, basic authentication. The loop is then started, and the first thing that is looked for is login failure. The script then looks for password expiry and handles it as a sequence of logical steps. A counter is used to ensure that the correct instance of the "New Password" message that is seen.

Finally, the script looks for the text "MENU" on the screen. When this is seen, the application menu has been loaded, and SecureLogin should close and return control to the user. The splash screen is closed at this point.

Dynamic Read Emulation - HLLAPI and DDE

One of the advantages of the HLLAPI and DDE emulators is their ability to directly read specific portions of the screen without affecting the user operation. This means that the script can continue to run while the user is using the application. This allows the script to handle more specific issues - specifically, the password change within an application.

In order for this to happen, the script uses the ReadText command. This has the following syntax:

	ReadText ?Variable Column Row

The use of HLLAPI comes from the days of the IBM Mainframe and Mini computers, the S/390, the AS400, and the System 34, 36, and 38. These had, in some cases, the ability to run macros based on the information on the screen. This functionality was added in to the software-based emulators and, when configured correctly, can be used to let SecureLogin handle the same information.

For a guide to configuring an HLLAPI emulator please see:
http://www.novell.com/coolsolutions/feature/14841.html

With IBM S/390 systems, the emulation screen displays system messages in the same place on every screen of data. When this is visible, SecureLogin can read the message and determine its action correctly.

The following screen shows the specific point on the emulator screen that we need to be aware of.

Figure - Emulator screen

When the script itself is considered, the messages to be looked for are the same as those used in generic emulators, that is:

• Login
• Password (Failure, Expiry)
• MOTD (Message of the Day)

However, the script itself gives much more flexibility. Because we can read specific portions of the screen there is no screen "blink." This means that the script can continue to run while the user is interacting with the emulator.

An example of an HLLAPI script follows:

Local ?runcount
set ?runcount 0
repeat
WaitForText "Request ====>"
if ?runcount eq 0
  repeat
    readtext ?message 9 2 2
    If ?Message eq ?NSL567001?
      call DoLogon
    EndIf
    if ?message eq "NSL564211"
      displayvariables "The Userid and/or Password is incorrect. Please re-enter them"
    endif
    if ?message eq "NSL564151"
      messagebox "Your password has expired. Please change it"
      call chpassword
    endif
    if ?message eq "NSL564181"
      messagebox "Your account has been disabled. Please contact the helpdesk"
      killapp emulator.exe
      endscript
    endif
    increment ?runcount
    delay 500
  endrepeat
else
  messagebox -yesno ?result "You have logged out. Would you like to log in again?"
  if ?result eq "Yes"
   call DoLogon
  EndIf
EndIf

Sub DoLogon
  Type $Username
  Type @E
  Delay 250
  Type $Password
  Type @E
EndSub

Although this script is incomplete (I have removed some of the subroutines to make it easier to read), it handles a number of issues. Each action is based on the message that is displayed at Line 2, column 2. When the message is one that needs to be dealt with, the script kicks in to action, performs a specific task, and then continues to run in the background.

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