This section contains information on the following:
Generally, don't use spaces when you specify variables. For example, specify $Username_Alias instead of $Username Alias. If you use spaces, enclose the entire variable in quotation marks (for example, "$Username Alias").
Stored variables are the most common style of variable used in SecureLogin scripts. They are preceded with a dollar sign ($). Use these variables to store the values used during the login process, such as usernames, passwords, and any other required details.
The values of these variables are stored against a script in the Directory under the User object. The values are encrypted so that only the user can access them.
In general, variables are stored separately for each application's script, so that the username variable is different for each application. However, you can set an application to read variables from another application's script. This is useful for applications that share user accounts or passwords. For details on how to do this, see the description in SetPlat.
If a stored variable is referenced in a script, and no value has been stored for that variable (for example, the first time the program is run), SecureLogin prompts the user to enter a value for the variable. This is an automatic process. It is also possible to manually trigger this process to prompt a user to enter new values for particular variables. For details on how to do this, see the description of DisplayVariables and ChangePassword.
Dialog
Title "Login"
Class #32770
End DialogType $Username #1001
Type $Password #1002
Click #1
In general, use runtime variables to store calculations, process data, or date information. You can also use runtime variables for temporary passwords and usernames.
Runtime variables are preceded with the question mark symbol (?). They have two modes: Normal and Local. Normal runtime variables are reset each time SecureLogin is started. Local runtime variables are reset each time the script is started. Runtime variables are Normal by default. For details on how to switch a runtime variable from General to Local mode, see the description in Local.
Runtime variables aren't stored in the Directory or the SecureLogin local cache. They are used straight from the computer's memory. For this reason, don't use runtime variables to store usernames, passwords, or other details that SecureLogin will need to access in the future. If runtime variables are used for such details, the user will be prompted to enter them each time the script is run or each time SecureLogin is restarted.
SecureLogin has one preset runtime variable: ?CurrTime. This variable is constantly updated to be equal to the number of seconds that have passed from January 1970 until the present time. This variable can also be used with the ConvertTime command to convert it to read the current time and date. This feature is generally used to enforce password changes every x days.
Dialog
Title "ERROR"
Class #32770
EndDialogLocal ?ErrorCount
Increment ?ErrorCount
If ?ErrorCount eq "2"
MessageBox "This is the second time you have received this error. Would you like to reset the application?" -YesNo ?Result
If ?Result eq "Yes"
KillApp "App.exe"
Run "C:\App\App.exe"
Else
Set ?ErrorCount "0"
EndIf
EndIf
SecureLogin is able to read the user's details (for example, the Windows version, which Internet browser is in use, or the password that was used to access the Directory) from the Directory and the workstation. These details are accessed by using internal variables. Internal variables have set names, which vary with the Directory in use and are prefixed with a percentage sign (%). See Internal Variables.
The following are examples of when these variables are used:
Passticket variables are used to generate one-time passwords based on a DES key and offset, similar to how VASCO tokens work. They are used differently than the other variable types. Passticket variables are preceded with the exclamation mark symbol (!).
To use a passticket variable, you must create and define numerical values for stored variables with the names $DESKEY and $DESOFFSET. The SecureLogin script parser uses these numbers to generate the one-time password.
After the stored variables have been defined, you use the following passticket variable to generate a password.
!Name of application definition
or
!default
For example, if you want to use a passticket variable for the Outlook application, you create two stored variables called $DESKEY and $DESOFFSET under the Outlook application definition. You then set values for the two stored variables. You can then use the variable !Outlook whenever you need to generate a one-time password.
You can also use !Default, which automatically reads the values from the current application definition.
If the $DESKEY and $DESOFFSET variables are not given values, SecureLogin generates random values the first time a password is generated and stores the values for later use.
SecureLogin is able to read details from the system and use the details to create variables that can be incorporated into the scripting language. These variables are automatically generated as runtime variables and can be used in the same manner within any application definition.
The following table lists the internal variables that SecureLogin supports.
SecureLogin stores your username and password in the form of a variable and its value. Your username and password are not included in the script. Instead, a variable is used in the script. The value of the variable is your username or password.
Logins consist of a set of variables. You can use any name for a variable. A variable can contain any text. As the following figure illustrates, the Variable column usually just contains the password and username for a particular application. However, in some more complicated applications, there might be other variables.
This example has two variables: username and password. The script for this application has the following line:
Type $Username
The variable $Username is written in the script. The value of $Username in this example is mkurz. When the script runs, SecureLogin looks for the variable $Username in the user's login details. There it finds and reads the value mkurz. SecureLogin enters the value mkurz into the login dialog box.
At runtime, the value of the variable $Username (mkurz) is read. However, in the script you only see the variable $Username.