ANZIO, AUTOMATED LOGINS, AND LIBRARIES Bob Rasmussen July 7, 1997 The following is text of a letter sent this date to users of Anzio in libraries. It may prove useful to others as well. ============================================================================ Greetings. This is Bob Rasmussen, of Rasmussen Software, producers of Anzio (the Windows telnet program). I'd like to provide some information and solicit some input on doing automated logins with Anzio. By that I mean, how can we set up a Windows icon or a web-browser icon, to automatically login to a particular library database? I'd like to cover both what is possible in Anzio now, and some enhancements we're working on. I'm especially interested in making sure we are aware of all of your requirements while we're making this set of changes. A DISCOVERY We recently discovered that there is an official standard for including a user name, and even a password, in a telnet cross reference. That is, not only can a web page contain: telnet://sitename or telnet://sitename:port it can also contain telnet://username@sitename or even telnet://username:password@sitename (of course ':port' is optional on the last two examples). Although the last example exposes the password to the user, it may be useful. The form 'username@sitename' however seems to offer some very useful opportunities for automation. That is, it would be nice to not have to tell the user to log in as "library", or whatever. Of course, for Anzio to get this information, the web browser being used has to pass it along. Early indications are that IE does, but Netscape does not. THE GOALS, AS I UNDERSTAND THEM Anzio is usually launched from either a Windows icon or a browser icon (cross-reference). In the former case, we have a great deal of flexibility in coding the command-line parameters for each icon. In the latter case, we are more restricted, because each icon contains only the cross reference, and the browser in use must be configured only one way. That is, we can't set up Netscape to treat one icon differently from another. That being said, I'll focus on the browser approach, because it's tougher. We might need to specify, then, any or all of the following: * host name * user name * password * Anzio settings (.DEF) file * Anzio keys (.KYS) file * a macro definition * a login macro to run upon startup HOW ANZIO WORKS NOW The following recaps how Anzio works now, as a starting point. Anzio's operating environment is contained in and influenced by three things: 1) The settings file (defaults to 'anziowin.def') 2) The keys file 3) The command line The name of the keys file is contained in the settings file. The keys file contains both function-key definitions and user macros. Keys files can be changed only with AnzioWin, not Anzio Lite. The host name is contained in the settings file, but can be overridden by the command line. The command line can contain any or all of: * the host name (and port) prefixed by "/h:" * the name of the settings file * a macro to run on startup * a macro definition limited to text characters Note that there are several things we CANNOT do, such as name a different keys file. We might, for instance, want to have several sites that we access with a common settings file, and always run an "L" macro, but we'd need a different keys file for each site. Nor do we currently separate out a userid if specified as "username@sitename". HOW ANZIO IS BEING USED NOW In talking with a few libraries, here is my understanding of how Anzio is being used now, when launched from a web site. 1. URL Specifies Site This is the traditional model. The cross-reference on the web page includes the host name to be accessed. The web browser is configured to include the "/h:" in the command it passes to Anzio. The only way to do an automated login with this model is if all logins are the same. 2. URL Specifies Settings File In this model, which is possible when one party controls both the web page and the PC setup, the cross reference names an Anzio settings file, such as "telnet://c:/anzio/mylib.def". The settings file contains the host name and other settings specific to that host. The web browser does NOT contain the "/h:" element, so Anzio would get a parameter of "c:\anzio\mylib.def" from the above example (the web browser reverses the slashes). To do automated logins, the browser can be configured to include "L" as a parameter, which would tell Anzio to run the "L" macro on startup. Then each settings file could have its own keys file, which would have an "L" macro to login to that site. It's a bit clumsy, but it works. 3. URL Specifies Launcher File This one's a bit trickier, and we're still investigating the possibilities. The URL references a file with a particular extension (either on the host or on the PC). The browser is configured to pass that file type to a third-party application which is some sort of a program launcher. The launcher parses (analyzes) the file to determine what to do, such as launching Anzio with certain parameters. For more info, check out http://www.library.wisc.edu/help/tech/launch_info.html Note that the techniques described there can launch a wide variety of resources. DEFINING A MACRO IN THE COMMAND LINE This one's fresh on my mind from a help session I did this morning. A librarian wanted to set up multiple Windows icons to access various OCLC resources. All would use the same settings file, the same keys file, and the same login script, except for one string (word) which identifies the database to be accessed. The solution was to use a command line parameter to define a particular macro ("z") with the name of the database. Thus if the command line contains /Dz LibraryLit this defines the "z" macro to contain "LibraryLit". The login macro can then CALL the "z" macro at the correct time to send its contents to the host. The librarian can then set up another Windows icon that specifies a different content for "z" in order to access a different database. Note that this scenario depends on there being different command line parameters for each database, so it does not lend itself to being used from a web browser. THE FUTURE Following is a list of changes from Anzio's "to-do" list, which we are currently working on. Taken together, I believe they will allow much greater flexibility in automating logins. 1. Parse Host Name When the command line contains a parameter of the form username@sitename or username:password@sitename parse it (take it apart), and connect to "sitename". Allow sending the username and/or password under macro control. 2. Generic Login Script We would provide a generic login script, that would accomplish: if we have a username waitfor "login" or "user" or "account" send username if we have a password waitfor "password" send password This would work in conjunction with item 1 above. 3. Parameter as Host Name or Settings File Currently, when Anzio sees a command line parameter more than one character long, and not starting with "/", it assumes that it is a settings file name. Under this change, if such a file did not exist, it would treat it as a host name (with username and password options as above). Thus the web browser would not have to be configured with the "/h:", and web pages could contain a mix of host names and settings files. In fact, by creating a settings file with the same name as a host, one could override the default handling of that host (this might require waiting for a 32-bit version of Anzio, so long file names could be handled). A variation on this would have Anzio examine the parameter's extension to decide what to do. 4. Settings File Specifies Startup Macro A setting in the settings file would indicate a macro to run on startup, such as "L". What the "L" DID would be dependent on the keys file. 5. Script File Specified in Command Line A new convention would say that a parameter with a particular extension would represent a script to run on startup. That script could be all text-based. Thus scripts could be stored on the host, downloaded by the browser, and passed to Anzio. This involves configuring the browser to recognize the particular extension and use Anzio to "open" it. Alternatively, the parameter could indicate a file of macros to be merged in. 6. Encoded Password A password can be entered and stored into the settings file, in an encoded form. It can then be sent to the host on macro command. Thus it is never stored on plaintext. THE INTENDED RESULTS With these changes in place, I can see the following scenario: * The browser is set up without the "/h:", so it passes the URL unchanged to Anzio. * A default "anziowin.def" is created with your "standard" settings. It is configured to auto-execute the "L" macro. No username or password is stored in this file. * The "L" macro is a generic login macro as described above. * For unscripted logins, the URL is configured simply as telnet://sitename Because there is no username or password, the login macro does nothing. * For generic logins, the URL is configured as telnet://user@sitename or telnet://user:password@sitename and the generic login macro does its thing. * For site-specific overrides, a settings file can be created with the same name as the host, or the URL can simply contain a file name. When Anzio sees a file of that name, that file takes precedence. The settings file could optionally contain the name of a particular keys file, with a different login macro. * For non-standard login scripts, the URL could specify file://filename.kys The browser would recognize the extension, and feed that file to Anzio. The named file would include an "L" macro that would override the generic one, and be executed on startup. The "filename.kys" could be either on the host system or on the PC. WHAT NOW? Now we need feedback! Would this make your job easier? Am I missing anything? Am I way off base? Please tell me. Feel free to address your response to the entire mailing list. This message will be made available in the documents archive of our web site. Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras@anzio.com company e-mail: rsi@anzio.com or sales@anzio.com or support@anzio.com -or- 71021,1365@compuserve.com ftp://ftp.anzio.com voice: 503-624-0360 http://www.anzio.com fax: 503-624-0760