        |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
HTML Connect User's Guide
CHAPTER 2
For demonstration purposes, one transaction is used throughout this document in the sample presented. You will be navigating to a Web site and entering a SKU number into a form to drive an inquiry. Also, you will change various options to retrieve different information from the Web site screen. You will be able see the details of the HTML Web page by viewing an XHTML representation of the Web page in an object called the ScreenDoc DOM. You can see the interaction of your selections and the result of them in the Action Pane. You will also be able to modify and edit your actions before saving your service.
There are many ways to go about creating HTML Components; however, the most commonly used steps in creating a simple HTML Component are as follows:
Create XML Templates required for any Inputs into the HTML or Outputs from the HTML transaction.
If you are going to access a secure site, create a Connection Resource containing any necessary security information.
Enter Record mode and navigate to Web page(s) for the information you want to capture.
Drag and drop information from the Input Part into the Web page to drive form interactions and drag and drop results from the Web page into the Output Part.
If your organization requires web users to go through a proxy server in order to get to the Web, you will need to provide proxy settings that Composer can use for "tunneling out" through the proxy.
NOTE: This is both a design-time and runtime issue. See further discussion below.
To configure Proxy Server Settings:
In Composer's Tools menu, choose Configuration to bring up the Configuration dialog (as shown above).
Click the checkbox labelled Use a proxy server. The Advanced button at the far right of the dialog will become enabled, along with the text fields labelled Address and Port.
In the Address text field, enter the IP address of the proxy server.
To expose additional settings, click the Advanced button. A new dialog appears:
If you wish to specify a different proxy address and/or port for FTP access than for HTTP access, make sure the Use the same proxy server for all protocols checkbox is unchecked. (Otherwise, the FTP text field will remain disabled.) Then supply the IP address and Port information for the FTP proxy in the text fields provided.
If your proxy server requires NTLM authentication in order to access its services, check the Requires NTLM Authentication checkbox.
If you did not check the Requires NTLM Authentication checkbox, continue to step 13. The Set button will be enabled if you have checked the Requires NTLM Authentication checkbox. Click this button. A new dialog appears.
In the User field, enter the user name that you were issued for authentication.
In the Domain field, enter the name of the realm to which this authentication procedure applies.
In the Proxy Settings dialog, in the text area labelled Do not use proxy server for addresses beginning with, enter a domain name if you wish to exclude certain domains from the authentication-handshake procedure. (A common case here is that you might want to exclude localhost and/or other in-house test domains.) You may enter multiple domains, separated by the pipe character.
If your HTML Components, once deployed, will still need to "tunnel out" through a proxy, you will want to carry your proxy settings over to the runtime environment.
The proxy settings you enter in the Configuration dialog are stored in a file called xconfig.xml (in Composer's \bin directory). In order for those settings to remain active for deployed components, you will need to make sure that the xconfig.xml file for Composer Enterprise Server (which exists on the app server) contains your proxy info. Open the design-side xconfig file in a text editor and look for the PROXYSERVERINFO element. You will see a section of data that looks approximately like:
<PROXYSERVERINFO>
<USEPROXYSERVER Desc="If on, the additional PROXY options are enabled (valid values are on | off)">on</USEPROXYSERVER>
<HTTPPROXYHOST Desc=" For Doc I/O, HTTP Actions etc., if network uses a proxy enter name here.">127.7.7.7</HTTPPROXYHOST>
<HTTPPROXYPORT Desc="Port number HTTPPROXYHOST listens on.">8008</HTTPPROXYPORT>
<HTTPNONPROXYHOSTS Desc="List of hosts that do not require a Proxy. Each hostname must be seperated by a pipe '|'.">localhost</HTTPNONPROXYHOSTS>
<FTPPROXYHOST Desc=" For Doc I/O, HTTP Actions etc., if network uses a proxy enter name here.">127.7.7.7</FTPPROXYHOST>
<FTPPROXYPORT Desc="Port number FTPPROXYHOST listens on.">8008</FTPPROXYPORT>
<NTLMCREDENTIALS>
<PROXYNTLMPROTECTED>on</PROXYNTLMPROTECTED>
<NTLMUSER>MikeM</NTLMUSER>
<NTLMPWD>ABYZsjbDcOk=
</NTLMPWD>
<NTLMDOMAIN>Argonaut</NTLMDOMAIN>
</NTLMCREDENTIALS>
</PROXYSERVERINFO>
Copy this section over to your server-side xconfig.xml file.
The Enterprise Connect for HTML is somewhat different than other types of Connectors in that no special connection resources need to be created in order to use it, as long as there are no special security requirements for visiting sites. The only time you will need to create special connection resources for your HTML Component is when one or more of your HTML Actions will be accessing secure web pages through HTTPS, Digest HTTP authentication, or NTLM (NT LAN Manager). In that case, you will need to set up one or more HTTP connection resources (as described further below) for each secure site that you intend to visit. You will then assign the appropriate connection resource to each HTML Action in your Action Model. (The procedure for associating a connection resource with an HTML Action is discussed in detail in Chapter 4 on page 35.)
Three main types of authentication are used in "secure" HTTP communication: Basic Authentication, Digest Authentication, and NTLM (NT LAN Manager). Composer offers three types of HTTP Connection Resources, corresponding to these three authentication protocols.
Basic Authentication is the most common type of HTTP authentication. If an HTTP client, such as a web browser, requests a page that is part of a protected realm, the server responds with a 401 Unauthorized status code and includes a WWW-Authenticate header field in its response. This header field must contain at least one authentication challenge applicable to the requested page. The client then makes another request, this time including an Authentication header field which contains the client's credentials. If the server accepts the credentials, it returns the requested page. Otherwise, it returns another 401 Unauthorized response to inform the client the authentication has failed.
One weakness of this type of scheme is that the user's credentials are transmitted "in the clear" and hence are susceptible to appropriation by eavesdroppers.
Digest Authentication works similarly to Basic Authentication, except that the user's credentials are encrypted before being sent over HTTP. Of course, merely encrypting a password before sending it over an open line doesn't add much safety, because the encrypted password can still be sniffed by a malicious program or individual and reused later. To keep this from happening,a host that supports Digest Authentication is required to generate a unique transaction ID value that can be associated with a given client-host session, and this unique per-transaction value—called a nonce—must be transmitted to the client and back from client to host as part of the authentication challenge. The significance of the nonce is that it can be used exactly once. If a hacker tries to reuse a stolen user-credential/nonce combo, authentication will fail since the nonce will be recognized by the host as having already been used. It is the host's responsibility to generate nonces and keep track of their use. Therefore you needn't concern yourself with this aspect of authentication when setting up an HTTP DigestAuthentication connection resource.
NTLM (or NT LAN Manager) Authentication is a Microsoft-proprietary authentication protocol. It involves transmission of a hashed key to the server; rehashing of the key to a new value, which is nonce-appended and sent back to the client, and resending (by the client) of a newly rehashed key. The hash algorithms on each end are different, and since a nonce is involved (see above), the scheme is relatively secure against replay attacks.
NTLM authentication is often encountered at the local proxy level as well as at the target website or remote host. If you are going out through an NTLM-protected proxy, you will want to set your NTLM options in the Tools > Configuration dialog as shown earlier in the section called "Proxy Server Settings". If you will be visiting a web site that issues NTLM challenges, you will need to set up an HTTP NTLM Authentication connection resource as described below.
The HTTP Basic Authentication connection type is provided as a means of letting you specify a security certificate and password info for access to a secure site. You will typically create one HTTP Basic Authentication connection resource for each secure site you visit. Later, you will assign the appropriate connection resource to each HTML Action that requires secure site access, per the description on page 35.
To create an HTML Connection Resource for a secure site:
From the Composer File menu, select New> xObject, then open the Resource tab and select Connection.
NOTE: Alternatively, you can highlight Connection in the Composer window category pane, right click your mouse button, then select New.
Select HTTP Basic Authentication Connection from the Connection Type pull down menu.
Enter a User ID and Password. These are not actually submitted during the establishment of a connection. They are simply defined here (the password is encrypted). The user will have access to UserID and Password variables from ECMAScript, allowing them to map UserID and Password as values into the screen. This way, no one ever sees the passwords.
If the site requires a client-side certificate:
Choose a Client Certificate by clicking on the Browse button and selecting the certificate file you want to use for this service connection.
Choose a Client Private key by clicking on the Browse button and selecting the client key file for security.
For steps above, please see Appendix A of this document for more detailed instructions about Digital Certificates.
Enter the Password for the Private key. Private key is another level of security for the owner of the Client Private Key.
Enter a Connection Timeout value in seconds. This represents the maximum amount of time that your component will wait for the web page to download. If a connection is not established or the page doesn't download in the time allotted, an exception is thrown.
Select the Default check box if you wish for this connection resource to be the first one shown in the pulldown list in the HTML Action setup dialog (page 35) from this point on.
The HTTP Digest Authentication connection type is provided as a means of letting you specify a username, password, and (optionally) a security certificate for access to a secure site that uses Digest Authnetication as described above. You will typically create one HTTP Digest Authentication connection resource for each secure site you visit. In building your component, you will assign the appropriate connection resource to each HTML Action that requires secure site access, per the description on page 36.
To create an HTTP Digest Authentication Connection Resource:
See the procedure for the HTTP Basic Authentication Connection Resource, above. The dialogs are the same except for the words Basic and Digest.
The HTTP NTLM Authentication connection type is provided as a means of letting you specify the credentials needed for access to a secure site that uses NTLM Authnetication.
You will typically create one HTTP NTLM Authentication connection resource for each secure site you visit. In building your component, you will assign the appropriate connection resource to each HTML Action that requires secure site access, per the description on page 36.
To create an HTTP NTLM Authentication Connection Resource:
From the Composer File menu, select New> xObject, then open the Resource tab and select Connection.
NOTE: Alternatively, you can highlight Connection in the Composer window category pane, right click your mouse button, then select New.
Select HTTP NTLM Authentication Connection from the Connection Type pull down menu.
Enter the Domain name for the site (as in "http://www.domain.com").
If the site requires a client-side certificate:
· Choose a Client Certificate by clicking on the Browse button and selecting the certificate file you want to use for this service connection.
· Choose a Client Private key by clicking on the Browse button and selecting the client key file for security.
NOTE: For steps above, please see Appendix A of this document for more detailed instructions about Digital Certificates.
· Enter the Password for the Private key. Private key is another level of security for the owner of the Client Private Key.
Enter a Connection Timeout value in seconds. This represents the maximum amount of time that your component will wait for the web page to download. If a connection is not established or the page doesn't download in the time allotted, an exception is thrown.
Select the Default check box if you wish for this connection resource to be the first one shown in the pulldown list in the HTML Action setup dialog (page 36) from this point on.
In addition to a connection resource, an HTML Component may also require that you have already created XML templates so that you have sample documents for designing your component. See Chapter 5, Creating XML Templates in the exteNd Composer User's Guide for more information.
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...
