 |
 |
 |
 |
 |
# COPYRIGHT (c) 2000, GALE GROUP. # ALL RIGHTS RESERVED # The use of this software is governed by a license agreement.
This program is installed on the Insite customer's intranet web site and implements one half of the Advanced Logon capability.
Its purpose is to redirect the user of the intranet web site into an appropriate Insite product location, already logged on, already at the exact screen and initial session conditions which have been configured by the administrator of the web site on which the InsiteLRTI has been installed.
The other half of Advanced Logon is the Insite Login Request Broker (InsiteLRB) which completes the login at the IAC web site.
Customer support is available to provide help on the technical and administrative issues of using this program.
Pointers to background reference material is available in the service-requirements document.
Obtain a local copy of the source code, build procedures and this documentation file:
| File | Format | Description |
|---|---|---|
| insitelrti.zip | INFO-ZIP archive | source code, build procedures, documentation. |
| insitelrti.tgz | GNU compressed (gzip) tar | source code, build procedures, documentation. |
| insitelrti_i386.zip | INFO-ZIP archive | Executable, html, and graphic components for manual installation on a windows nt intel platform. |
| insitelrti_solaris_sparc.tar.Z | standard tape archive (tar) compressed using adaptive Lempel-Ziv coding compress command. | Executable, html, and graphic components for manual installation on a solaris sparc platform. |
This program expects to be run in a standard CGI environment of a web server. Any of the following environment variables may be utilized, depending on the configuration settings in the ini file: SERVER_NAME, SERVER_PORT, SCRIPT_NAME, PATH_INFO, QUERY_STRING, REMOTE_HOST, REMOTE_ADDR, REMOTE_USER. The SERVER_NAME variable is read in order to enhance the security of the issued ticket.
There are predefined targets for Unix variants solaris, osf1, linux, hpux, and irix. The build procedure dispatches off the value of the uname command. If something doesn't work in your version you might as well try the generic target.$ make -f insitelrti.makefile
Create as many or as few usernames as required, whatever is convenient for purposes of accounting and access control. The passwords should be chosen to be long and difficult to guess. They don't need to be typed by users because they are entered only in the insitelrti.ini file. The accounts should be marked as shared to prevent the end user from making any modifications to it, such as changing the password. The IP address restriction feature is not supported.
The insitelrti.ini file must of course be protected as confidential data. Users should not have access to it, otherwise they could log into the Insite products directly, bypassing the advanced logon system. See the server_conf section for examples of how to protect this file.
Also, if you are going to utilize the query string in the url for invoking the InsiteLRTI be aware that any user could modify any data contained in it.
The SERVER_NAME and time is transmitted as part of the Insite Login Request Ticket. This is to enable the broker to guard against the reuse of tickets. Assuming a moderate amount of clock synchronization between the customer site and IAC, the broker can reject a ticket which has a timestamp too far in the future or was issued too long ago, and keep a timestamped table of all tickets processed in the last N hours and reject duplicate requests.
Browsers recently tested, such as NSG 3.01 (Netscape Navigator), and MSIE 4.01 (Microsoft Internet Explorer) transmit a referer url which indicates the page on which the link to the insitelrti was located, and not the address of the insitelrti itself. This is good behavior, especially considering that some uses of insitelrti_menu might reveal the password used to access the Insite products in plaintext. However, some older browsers may behave differently with respect to how referer url is handled in the presence of the kind of redirection-mode responses utilized by the ticket issuers.
If web client-server authentication is enabled for the location in which the InsiteLRTI resides then the REMOTE_USER variable is available for use in directing the user to a particular application, product and/or computing the default charge_code, for example:
|
|
|
|
|
|
The link to InsitePro above was created using the following html:
<A HREF="insitelrti.cgi?appl=insitepro">
<IMG SRC="insitepro_logo.gif" ALT="Click here for InsitePro"
BORDER=0></A>The simplest configuration would cause all users to go to the Insite product, all under the same username, for example:
[DEFAULT] application=insite username=companyXYZusername password=gg293817xty29771827
The ini file mechanism works this way:
The parameters that need to be filled in before a logon request ticket can be issued are:
| Parameter Name |
Description |
|---|---|
| error_message | If this is provided then the login request ticket is not issued and instead the error message is displayed. A zero length error message means no error in this case, overriding any other default cases. |
| lrb | The URL of the Insite Logon Request Broker. In general there is no need to change this from its default value. The parameter is provide for diagnostic test purposes and for the configuration of customers with special needs. The ticket issuer uses this URL in a redirect (see goto_status parameter). If the URL lacks protocol/host or directory prefix then one is inserted by the ticket issuer. |
| goto_status | Some special customer proxy server and firewall situations may require tuning of this HTTP specific parameter. There is usually no need to change this from its default value. |
| application | The trade-name, in lowercase, of the application to be used: insite, insitepro, insitesales, insiteaas,csweb |
| username | The username which would be used in a manual logon to the application. |
| product | The name of the product or database specific page into which to send the user of the application. This field is optional. |
| charge_code | The charge code to enter into the application. This field is optional and used only for Insite and InsitePro. If the value is PromptUser (case sensitive) then the user session starts out on the charge code entry page. This works only for the Insite application currently. |
| password | The password which would be used to manually log into the application. This parameter is usually obtained by looking up the username in the [AUTHENTICATION_SECRETS] section of the config file |
The effect of a query string in the URL used to invoke the InsiteLRTI is to provide a way to vary the names of the configuration sections [section_name]. If a query string is available then all data lookup will first try to find [section_name?query_string] and if that fails it will try [section_name]. Unless the specialize_using value is path_info in which case the path info is used to vary the names of the configuration sections instead.
Or the product string can start with a slash "/" in which case it is a "saved-search" url, extracted from a previous Insite session, the details of which will be documented elsewhere. This will prove useful in setting up MSIE 4.0 channel files and other similar applications.
| Parameter Name |
Description |
|---|---|
| debug | Lets you turn on the debug feature without setting an environment variable. This should be used with caution since it can disclose confidential information to the users of your web site. |
| server_name | Lets you charge what server name is reported to the broker. This information is used for debugging and customer support purposes. |
| server_os | Lets you charge what server_os is reported to the broker. This information is used for debugging and customer support purposes. |
| issuer_revision | Lets you charge what issuer_revision is reported to the broker. This information is used for debugging and customer support purposes currently, but should not be changed lightly because it may in the future be used in the protocol if it should need to change in any radical way. |
| time_offset | If your local time() needs to be set in some unusual way then this offset allows the ticket issuer to compensate for that fact by adding a value in seconds. |
| lrti_url | In general there is no need to set this parameter since it is
automatically set to URL with which insitelrti is invoked.
But if there is any need to override the default value due to
firewall, proxy server, DNS setup etc., then lrti_url can be
set to any desired value. Value of CGI variables, SERVER_NAME,
SERVER_PORT, SCRIPT_NAME, PATH_NAME and QUERY_STRING can be
included in lrti_url value by including corresponding conversion
specification, %h, %o, %s, %p, %q.
e.g., lrti_url=http://www.mycompany.com:%o%s%p?%q |
| specialize_using | If specified as query_string (the default) then the query string of the url which was used to invoke the ticket issuer is used to vary the section names in the ini file. If specified as path_info then the path portion of the url following the name of the ticket issuer executable is used instead, allowing the query string to be used to store values to be dynamically passed into the parameter result set, if configured in the init file by using an "@" followed by a query string key name as the value of a parameter. |
Alternatively if you must pass arguments then create a small batch command file or shell script and pass the information as environment variables.
| env | Description |
|---|---|
| INSITELRTI_INIT | The name of the init/db file. Useful when it is impossible to secure the insitelrti.ini file in its default location. |
| INSITELRTI_LRB | The url of the logon request broker, an IAC location that need not change. |
| INSITELRTI_DEBUG | If non-zero a verbose diagnostic trace results. This option is intended for use by IAC's software QA group. |
A customer may dispense with the insitelrti_ini.c source module and instead create a functional equivalent which further leverages the existing intranet account management infrastructure. The IAC supplied insitelrti_ini mechanism may not be efficient enough to handle insitelrti.ini files containing thousands of user records.
The customer specific source file would include insitelrti.h, and define a procedure insitelrti_lookup.
All that is expected of the insitelrti_lookup procedure is that upon successful completion it fill in the structure fields application, username, password, product, and charge_code, and return NULL, and upon unsuccessful completion it return an error message string which may be printed and deallocated.
This allows for customized logon screens to be generated, allowing javascript or other constructs to do error checking on charge codes or other fields. View the source code to this page for a detailed example:
The form input names support by insitelrti_menu.cgi are the same as supported by the ini file driven insitelrti.cgi program:
If these techniques are to be used at a customer site then appropriate distributable components of Advanced Logon should be installed at the customer site, which is to say inside the customers network security perimeter. In particular the use of insitelrti_menu referenced via url to the IAC facilities represents a security risk which can be understood by reviewing the data which is transfered.
The idea here is to utilize client-side javascript to compute the required charge-code and to make changes to the usernames and passwords in order to map customer specific credential conventions into ones suitable for use with the Account Administration System.
Javascript is not the only possible enabling technology to do this sort of thing, it is just very convenient. A customer with C-programming capability in his own Web-Server/CGI environment could accomplish the same thing, and more, by modifying the insitelrti_lookup procedure in the insitelrti_menu.c module provided with the Advanced Logon kit.
The following example form requires that the user enter a username, password, project code and sub project code. A charge_code is computed by combining the project and subproject codes. These things are enforced by a bit of Javascript code that is visible in the source to this example.
The following items would normally be hidden parameters, but are visible in this example for purposes of illustration.
| username prefix | |
|---|---|
| password prefix | |
| application | |
| debug |
<!-- This javascript would be customized to enforce the business rules
associated with charge codes, etc. -->
<SCRIPT LANGUAGE="Javascript">
function compute_insitelrti_menu_arguments()
{var flag;
flag = true;
if (document.insitelrti_menu.customer_username.value == "")
{alert("username must be entered");
flag = false;}
if (document.insitelrti_menu.customer_password.value == "")
{alert("password must be entered");
flag = false;}
// The exact syntax, number of characters, alphabetic, numeric,
// and other conventions could be easily checked here as well.
if (document.insitelrti_menu.project_code.value == "")
{alert("a valid project code must be entered");
flag = false;}
if (document.insitelrti_menu.subproject_code.value == "")
{alert("a valid sub-project code must be entered");
flag = false;}
// More sophisticated algorithms besides simple string concatenation
// could be applied here, particularly to the password values.
// But a prefix is sufficient to prevent collisions with usernames
// created by other companies.
document.insitelrti_menu.username.value =
document.insitelrti_menu.username_prefix.value +
document.insitelrti_menu.customer_username.value;
document.insitelrti_menu.password.value =
document.insitelrti_menu.password_prefix.value +
document.insitelrti_menu.customer_password.value;
document.insitelrti_menu.charge_code.value =
document.insitelrti_menu.project_code.value + "_" +
document.insitelrti_menu.subproject_code.value;
return(flag);}
</SCRIPT>
<P><CENTER>
<FORM ACTION="insitelrti_menu.cgi"
METHOD=GET
NAME="insitelrti_menu_fancy"
onSubmit="return compute_insitelrti_menu_arguments(this);">
<TABLE BORDER=0>
<TR><TH ALIGN=RIGHT>Username:</TH>
<TD><INPUT name="customer_username" type=text size=20></TD>
<TD ROWSPAN=3><IMG SRC="insite_logo.gif"
ALT="IAC Insite"></td></TR>
<TR><TH ALIGN=RIGHT>Password:</TH>
<TD><INPUT name="customer_password" type=password size=20></TD></TR>
<TR><TH ALIGN=RIGHT>Project Code:</TH>
<TD><INPUT name="project_code" type=text size=20></TD></TR>
<TR><TH ALIGN=RIGHT>Sub Project Code:</TH>
<TD><INPUT name="subproject_code" type=text size=20></TD>
<TD ALIGN=CENTER><INPUT TYPE=SUBMIT VALUE="Log On"></TD>
</TR>
</TABLE>
<INPUT name="application" type=hidden value="insite">
<INPUT name="goto_status" type=hidden value="302 Temporary Relocation">
<INPUT name="product" type=hidden value="">
<INPUT name="lrb" type=hidden value="http://iac-insite.com/wbs/insitelrb.cgi">
<INPUT name="error_message" type=hidden value="">
<INPUT name="username" type=hidden>
<INPUT name="password" type=hidden>
<INPUT name="charge_code" type=hidden>
<INPUT name="username_prefix" value="YOUR_COMPANY_NAME_" type=hidden>
<INPUT name="password_prefix" value="some.secret." type=hidden>
</FORM>
</CENTER>
The first supported revision of the insitelrti.c file is 1.9, it supports all options and is not expected to be changed unless bugs are found. Older versions of the ticket issuer are expected to run with newer versions of the broker.
Version 1.10 of insitelrti.c fixes problems with some charge code and server name fields containing illegal characters.
Version 1.11 introduces the ticket issuer version and server type declaration in order to improve customer support.
Version 1.12,1.13 insitelrti.ini filename now calculated from SCRIPT_NAME, insitelrti_menu.c module introduced.
insitelrti_ini.c,v 1.7 adds additional wildcarding to [REMOTE_ADDR] section.
As of 25-AUG-1997 the Logon Request broker, residing at http://iac-insite.com/wbs/insitelrb.cgi, revision 1.9, supports the product parameter only for the application insite. The charge_code parameter is supported only for insite and insitepro. Revision 1.12 is the current release level, which supports some application integration options and fixes a bug with illegal charge code field data.
23-DEC-1997. insitelrb.cgi version 1.17 handles charge_code=PromptUser. And insitelrti version 1.15 handles time_offset and server_name and other override parameters.
17-FEB-1998. insitelrb.cgi version 1.21 handles enhanced product name, insitelrti version 1.17 handles issuing saved-search product names.
9-MAR-1998. Insitelrti revision 1.18 fixes a bug where corrupt tickets may be issued, with garbage character data before the query string, under some operating conditions, the bug having been introduced 23-DEC-1997.
25-MAR-1998. Insitelrb.cgi version 1.19 with insitelrti_ini version 1.10 includes support for specialization via path_info, freeing up the query string so that the functionality of the init-file configured ticket issuer and the menu/from version are combined.
1-MAY-1998. Insitelrb.cgi version 1.25 supports csweb application (computer select web).
2-JUNE-1999 This release of Advanced Logon supports Insite 2 application in two functions, support for normal login procedure that is similar to other applications and support for Insite 2 alert mails. Insite 2 users who subscribe to alert mails can now view articles (or launch Insite 2) directly from their mail reader.
4-FEB-2000 Updated AdvancedLogon has two new features :
This document revision is $Id: insitelrti.html,v 1.39 1998/06/15 13:24:33 gjc Exp $ the production version of which resides at http://iac-insite.com/wbs/insitelrti.html.
| Error Message or Condition |
Component Involved |
Possible causes and corrective actions |
|---|---|---|
| System error or garbage or noise data display in browser after clicking on the ticket issuing link | ticket issuer |
Improper build or installation of ticket issuer on customers intranet web server. |
| Insite Logon Request Ticket Issuer lookup failure | ticket issuer |
The intranet web site administrator has configured this error message in the ticket issuer init file he maintains. misconfiguration of that file or of the web page containing the ticket issuer link url is a possible cause, but a more likely cause would be indicated in the rest of the error message which was configured in the init file through the use of the error_message parameter. |
| Insite LRB url is empty | ticket issuer |
misconfiguration of init file lrb parameter. |
| Insite application name is empty | ticket issuer |
misconfiguration of init file application parameter, or unanticipated client request. |
| Insite username is empty | ticket issuer |
misconfiguration of init file username parameter, or unanticipated client request. |
| Insite password is empty | ticket issuer |
misconfiguration of init file password or authentication secrets parameters, or unanticipated client request. |
| INSITELRTI_VERSION mismatch | ticket issuer |
Improperly built or installed ticket issuer. |
| struct insielrti mismatch | ticket issuer |
Improperly built or installed ticket issuer. |
| Cannot open init file | ticket issuer |
Improperly installed ticket issuer or intranet web server system problem. |
| Application not specified | request broker |
Ticket not properly redirected from issuer to broker. |
| username not specified | request broker |
Ticket not properly redirected from issuer to broker. |
| ticket time not specified | request broker |
Ticket not properly redirected from issuer to broker. |
| ticket server not specified | request broker |
Ticket not properly redirected from issuer to broker. |
| digital signature missing | request broker |
Ticket not properly redirected from issuer to broker. |
| IAC Application specification is unknown | request broker |
misconfiguration of ticket issuer init file. |
| Server Error (Application Level) | request broker |
System or database problem at IAC. |
| failed to verify username | request broker |
misconfiguration of username parameter in ticket issuer init file. This error message may be obscured in the future for security reasons. |
| failed to validate logon. check ip address | request broker |
misconfiguration of end-user accounts. The ip address restriction feature is not supported for advanced logon. |
| Failed to authenticate: The Account is not active | request broker |
misconfiguration of end-user accounts. |
| Failed to authenticate: Invalid IP address for user account | request broker |
misconfiguration of end-user accounts. The ip address restriction feature is not supported for advanced logon. |
| Failed to authenticate: No Product Allowed | request broker |
misconfiguration of end-user accounts or ticket issuer init file username parameter. The username specified is not allowed to log into the application specified. |
| failed to verify digital signature of ticket | request broker |
misconfiguration of end-user accounts or ticket issuer init file. The password parameter which is the shared secret between the ticket issuer and the request broker is different between the two components. |
| Your ticket appears to have been issued in the future. | request broker |
Clock time mismatch between ticket issuer server and request broker server. Error message has details of what time the server thinks it is. |
| Your ticket appears to have expired. | request broker |
Either a clock time mismatch between ticket issuer server and request broker server or some client web browser has bookmarked, saved, or cached the request ticket for later use, or a proxy server cache mechanism is involved in some way. |
| Error starting session | request broker |
The request broker was unable to start a session on the application server, possibly due to server or network or application problems at IAC. |
| product specification unknown | request broker |
Misconfiguration of ticket issuer init file product parameter. |
| url malformed | request broker |
Some internal communication or protocol problem between the request broker and the application. |
| Error locating session id | request broker |
Some internal communication or protocol problem between the request broker and the application. Or the application is failing to allow the user to logon for some other reason such as IP address restrictions or concurrency limits. |
| Session id appears malformed | request broker |
Some internal communication or protocol problem between the request broker and the application. |
| No host defined for application | request broker |
Internal request broker configuration problem. |
| No url defined for application | request broker |
Internal request broker configuration problem. |
| No fcn defined for application | request broker |
Internal request broker configuration problem. |
| Undefined LRB fcn | request broker |
Internal request broker configuration problem. |
| Insite Logon Request Broker failed to initialize | request broker |
Internal request broker configuration problem. |
| Server Error (Application Level) dbopen failed | request broker |
May take up to 120 seconds to see this error, which is caused by the unavailability of the database server or some configuration problem. |
| Sorry! The Username and Password you supplied were not confirmed. | insite application |
misconfiguration of end-user accounts. The ip address restriction feature is not supported for advanced logon. Or some system level error at IAC. |
[DEFAULT] error_message=No specific application specified in URL specialize_using=path_info username=XXXXXXX password=YYYYYYY [DEFAULT?/insite] application=insite product=@search [DEFAULT?/insitepro] application=insitepro
The blank error message in the [OK] section will override, and therefore nullify the error message in the [DEFAULT] section. But only clients browsing from specific addresses will be directed to the [OK] case.[DEFAULT] error_message=Sorry, your PC is not authorized to use this link. specialize_using=path_info [REMOTE_ADDR] 206.15.106.143=OK,charge_code=KIOSK 1 206.15.106.142=OK,charge_code=KIOSK 2 206.15.105.130=OK,charge_code=KIOSK 3 206.15.105.*=ALMOST_BUT_NOT_QUITE [OK] error_message= application=insitepro username=kiosk.user password=secret.as.it.is product=@search [ALMOST_BUT_NOT_QUITE] error_message=Please call 555-3333 x345 for help.
Only a subset of these individual users are to be allowed access to the insite product, and each intranet user is to be logged into the Insite product using a unique username in order to provide maximum accounting information. These usernames must be created by the account administrator, and in this case all starting with the company name acme to ensure uniqueness. Finally, there are three different icons to be configured on the intranet web pages, with pointers to each of the three different insite applications.
The following init file implements these ideas for the usernames fred, jim, and sam.
[DEFAULT] error_message=User has not been authenticated to web server. [DEFAULT?appl=insite] application=insite [DEFAULT?appl=insitepro] application=insitepro [DEFAULT?appl=insitesales] application=insitesales [REMOTE_USER] fred=OK,username=acme_fred,password=XXXXXXX jim=OK,username=acme_jim,password=XXXXXXX sam=OK,username=acme_sam,password=XXXXXXX *=BAD [OK] error_message= [BAD] error_message=User has not be authorized to use an Insite application.
The section on error messages may also be useful.
Finally the insitelrti_env.cgi program may be run on your server so that you can observe the input parameters which would be seen by the ticket issuer. For example:
QUERY_STRING = "appl=insite" REMOTE_HOST = "curia.vatican.va" REMOTE_ADDR = "194.91.153.247" REMOTE_USER = "peter" server_os = unix
With this kind of information in hand you could then execute the insitelrti.cgi program from an interactive command line, establishing the same environment parameters and including others to enable full debug mode operation.
Usually it enough to carefully inspect the information so that proper configuration of the insitelrti.ini file may be made.
Also the following configuration information has been used in the httpd.conf file of Apache version 1.2 servers.
# Project all ini and conf files. <Location /*.ini*> deny from all </Location> <Location /*.conf*> deny from all </Location>
Use the Microsoft Internet Service Manager to configure the Directory Properties such that access attributes include Execute but not Read.
Note that the REMOTE_USER parameter in this environment may consist of DOMAINNAME/USERNAME and not just a plain USERNAME.
Also the following line placed in the PathCheck sequence of the <Object name="default"> section of the obj.conf file can be used to protect all ini and conf files, no matter where they are located.
PathCheck path="(*.ini*|*.conf*)" fn=deny-existence
Note: This feature is currently unadvertised and unsupported because it depends on implementation characteristics of the insite product which will change in the near future, and it does not consistently support certain features such as the charge_code.
But it does allow for a demonstration of how an Information Architect might create a web page or email message containing links to predefined searches which can then be used directly and refined by other people. The techniques are also useful in the definition of MSIE 4.0 Channel's, see CHANNELS.
An Insite product session url currently starts with the usual http:// and a host name, but is then followed by a cryptic sequence of session id characters. The data context of the URL then continues starting with the sequence /CTX.
An advanced logon ticket may be issued with this data context specified as the product string. The behavior of the system will be to create a new logon session which starts out with the Insite product logged on and pointing into the same place as the previous session was pointed, but without all the intervening history used to get to that point.
Here is an example insitelrti.ini file:
[DEFAULT] application=insite username=XXXXXXXXXXX password=XXXXXXXXXXX product=/CTX_DB01^/SEA?cit1=1&citn=20&uspec=1&str=microsoft&sty=lkw
It is also possible for the webmaster to configure the insitelrti.ini to allow users to pass through their own saved product session urls through the authentication provided by the ticket issuer. This init file for example would allow a user to specify a url of the form http://host/cgi-bin/ticket.cgi/search?search=XXXXXXXXXXX where XXXXXXXXXXX would be a url encoded saved product search URL.
[DEFAULT] specialize_using=path_info application=insite username=XXXXXXXXX password=XXXXXXXXX debug=0 [DEFAULT?/search] product=@search
The creation of these urls is a bit tricky, and the auxiliary use of cgi script or java script would be helpful.
Exactly how this technical feature may be exploited in order to supply advanced application functionality is currently under investigation, but there is nothing to stop the enterprising customer webmaster or user from taking advantage of it now as a way of providing convenient access into the Insite product line.
The first step is to create a file named (for this example) insite.cdf on a web server or on the local file system. If users normally access Insite through a locally maintained ticket issuer, at for example, http://intranet.something.com/insite/cgi-bin/insitelrti.cgi then the following file would be suitable:
<?XML VERSION="1.0" ENCODING="UTF-8"?>
<CHANNEL HREF="cgi-bin/insitelrti.cgi"
BASE="http://intranet.something.com/insite/">
<TITLE>Insite Channel</TITLE>
<ABSTRACT>This is a test of using Microsoft Active Channels to get
into Insite</ABSTRACT>
<LOGO HREF="insite_logo.gif" STYLE="IMAGE"/>
<LOGO HREF="insite_logo.gif" STYLE="ICON"/>
</CHANNEL>If the insitelrti.cgi has been configured by your administrator to make use of the specialize_using=path_info feature and the product parameter is set to @product then the channel may include a user-customizable saved search.
Or alternatively if your normal access to the Insite product is via the logon page where you manually enter your USERNAME and PASSWORD then this channel definition file would be suitable:
<?XML VERSION="1.0" ENCODING="UTF-8"?>
<CHANNEL HREF="insitelrti_menu.cgi?application=insite&username=USERNAME&password=PASSWORD"
BASE="http://www.iac-insite.com/wbs/">
<TITLE>Personal Insite Channel</TITLE>
<ABSTRACT>This is a test of using Microsoft Active Channels to get
into Insite</ABSTRACT>
<LOGO HREF="insite_logo.gif" STYLE="IMAGE"/>
<LOGO HREF="insite_logo.gif" STYLE="ICON"/>
</CHANNEL>With either method when you then use your browser to open the location containing insite.cdf you will see a dialog box and should follow the directions in this table:
| Dialog Box Title: | Add Active Channel(TM) content |
|---|---|
| Descriptive Text: | This will add the channel to your channel bar. Would you also like to subscribe to the channel? |
| Item to choose: | No, just add to my Channel Bar |
| Button to push: | OK |
Do not choose the subscription or advanced features unless you want to go down a path investigating behaviors that haven't been looked at by developers of Insite yet. This is not recommended.
The resulting channel bar will be highlighted with the insite product logo when you click on it.
Finally, with the insitelrti_menu.cgi method it is also possible to include a &product=XXXXX specification to link directly into a particular citation list or search result. The value XXXX would have to be properly HTML encoded for this to work.
The same thing can be done using insitelrti.cgi configured to allow pass through of information from the query string into the product parameter.
Make note of the following environment information:
Then add the debug=1 setting to the [DEFAULT] section of your insitelrti.ini file.
Then issue a ticket by clicking on the ticket issuing url. Use the browser [Save As], [HTML] capability to save the output (exact html, not just text) to a file.
Click on the URL you observe in the previous output. If the result is an error then again use the browser [Save As] [HTML] capability to save the result to a file.
Send all the output files and the insitelrti.ini file to IAC customer support, preferably as attachments to an email message in such a way that the files will not be corrupted in any way during the transfer process. Note that this will disclose some passwords which you will want to change once things have been debugged.