SDSS Subscription Server Troubleshooting Guide

[help][faq][howto][login]

This is a work in progress.  We will add more problems as we become aware of them.

Login Loop.  My end-users report that once they log in successfully, they get a message saying they are not logged in.  They log in again, and get the same login message.

This problem normally occurs in three cases:

1. End-user's browser is using cached page instead of drawing page from the server.   The cached page has logic in it indicating that the user is not logged in.   When the user logs in again, the page is not updated, but rather is read from cache again, hence the loop.
   
   Solution:  We believe we have resolved this issue by putting logic in affected Softpages which require them to be refreshed when called.  At the time of this writing, we are aware that this coding *might* not work for IE 5.0.  If a user experiences this problem repeatedly, please ask him to empty the cache in his browser.
   
2. Server not inserting or Browser not accepting cookies.  The SDSS login programs are designed to insert two cookies into the end-user's browser: one from the SDSS host and one from your host.  If the cookie is not inserted, loading of certain sD Softpages will fail because their logic indicates the user is not logged in -- hence, the login message.
   
   Solution:  Make sure end-user understand's that his browser must be configured to accept cookies in order to access your infobase subscription. Also, check to make sure your HTTPD server does not have any problems inserting cookies into certain browsers.  
   Also, we have a little test HTML file called "test.htm" which can be downloaded from the SDSS Softpage option on the Client Top Menu when you log into SDSS as a Source Client.  You can download this page and put it somewhere in your HTML directory where it can be accessed by the general public.  Accessing this page will let a user know if the cookie has been installed from your server or not.  If it has, and he continues to get the login message, then the problem could be #1 (cache) or #2 (proxy). 
   
3. Proxy server changing address.  There are some ISPs who use proxy servers which change or rotate the IP address in a user's browser several times during a session.   Since SDSS uses the IP address the user had when he first logged in to identify him from that point on, SDSS is unable to identify the user as logged on when the proxy server changes the IP address.  Hence, the repeated login message.
   
   Solution:  This should not happen, and when it does, it has to be worked out between the end-user, his ISP and the browser he is using.

After successful login, browser reports infobase/softpage/URL not found.

A user logs in, the screen reports successfully, only to get an error indicating that the infobase, softpage or URL was not located. 

Solution: More than likely, you have entered into the Subscription Record an incorrect URL for either the Subscription Login URL or the Subscription Start URL.   The Subscription Login URL is the SDSS page titled "securej_Login.htm" and it must be a) installed on a normal non-sD HTML directory, b) renamed to a secret alias, and,  c) reachable by any browser via the Internet.  The Subscription Start URL is the final destination for a subscription login; When the user logs in, this is the page you want to come up on his browser after the login process has completed.

User can access secured sD infobase without logging in.

A user who is NOT a subscriber and has NOT previously logged in is able to access a "secured" infobase.

Solution:  The user can only access an sD infobase via a Softpage.  SDSS "secures" an infobase by restricting access to the Softpages which can be used to access the infobase.  When you create the settings group SECUREJ, you must make sure that EVERY Softpage which can be used to access intelligible (i.e., Document, TOC ) information from an infobase has a SDSS Softpage alias.  There are only a set number of these pages which come with the default siteDirector setup.  These are the ones we cover with the default SDSS Softpages.  You may have created others.

Example:  You create a SECUREJ settings group.  You create aliases for all of the default Softpages.  However, you have a Softpage you created called "SeeDocument.htm".  Even though "SeeDocument.htm" is not in the SECUREJ settings group, it can be used to access any infobase by using "softpage=SeeDocument" in the sD call URL.  You can prevent this from happening by doing one of two things:

1. In SDCONFIG, you drag "SeeDocument.htm" into the SECUREJ settings group and assigning it to a default SDSS Softpage.  This way, when someone attempts to use "SeeDocument.htm", they will be using an SDSS page and will be required to log in.
2. Get SeeDocument.htm converted for SDSS use.

End-user reports getting message "Infobase Record Not Found"

This means you have successfully secured the infobase with the SDSS Softpages, but have not created an Infobase Record.  When SDSS receives an infobase query,  it first looks for the "infobase=" part of the query string to determine the infobase alias.  Once the infobase alias is identified, the SDSS Infobase file is searched for a match.  If a match is not found, you get this error.

Soution: Log into SDSS Client Menu, select "SD Security Maintenance", "Infoabase", "add", and create record for the infobase alias.

End-user reports getting message "Subscription Record Not Found"

This means you have successfully secured the infobase with the SDSS Softpages, created an Infobase Record., but you have not created a Subscription Record.  When SDSS receives an infobase query,  it first looks for the "infobase=" part of the query string to determine the infobase alias.  Once the infobase alias is identified, the SDSS Infobase file is searched for a match.  If a match is made, SDSS then looks for the Subscription Record for this infobase.  If this record is not located, you get this error.

Soution: Log into SDSS Client Menu, select "SD Security Maintenance", "Subscription", "add", and create record for the subscription record for the infobase(s) in question.

My logo does not appear on the Subscription Order page (where end-user fills out credit card info).  Instead there is a "key".

The order page is a secured page,  which means all elements in it must come from a secure server.  Your logo comes from the URL you entered into the Logo URL field of your Source Record.  For it to be secure, and appear on the order page, your logo needs to be on our server.

Solution: Please contact your SDSS System Administrator in order to upload your logo to him.  Once uploaded, you need to change your Logo URL in the Source Record to: https://dns.scbbs.com/images/<your logo filename>

(Please don't forget that this is "https", not "http").