This program, that creates the user ID and passwords and automatically logs people into secure web pages, can be a bit picky.  The program uses “cookies” that are tied to domain names.  This feature of “cookies” can make it difficult to debug why the form is not working correctly.  Therefore, this section is set up to help you diagnosis problems you might have while setting up this page.

As mentioned, this process uses “cookies” to allow verify the users information as they are passed to secure web pages.   “Cookies” is tied to a domain name which means that the domain name must the same throughout the process.  This can be more complicated than appears on the surface.  Following are some symptoms and solutions.

Symptom: The form will create the user and password but will not log the user into the secure form.

Possible problem: The correct web page has not been specified. 
Possible solution: The specified page must be within a password protected directory.  The URL to the page should specify the relative path from the home directory.  For example, if the page is called index.html in the secure directory, Secure, then the SUBSCRIBEredirect should be “directory/index.html.”

Possible solution: Make sure that the domain name has been associated with the web site using the Domain Name Manager.  Sometimes if the subdomain is used, there are problems.  If the account has multiple domain names, this could cause a similar problem.   The problem comes because the domain name specified in the Forward Users URL in the form envelop block may be different from the one the visitor uses or the one specified in the Domain Name Manager as a default.  This may cause the form to not function correctly.   In this case, you must remove the domain name from the URL in the Forward Users URL and use the relative URL as follows: /cgi-bin/EZForms/subscribe/handler.cgi?session_id=[session_id]&submitter_id=[customer_id].  This way, the form will use the domain name used by the person arriving at the form.