Offering Cookie Web Authentication provides a drastically different web operation as well as look and feel for your Wildcat! Web Server:

• No more user browser login POPUP boxes.

• User login is now performed using a HTML login page or login user id/password form fields in your public web page.

• User has ability to completely log off the web server without the need to close the browser by clicking the special Wildcat! "/logout" URL.

Please keep in mind the user's browser must support and enable session cookies and javascript in order to use Cookie Web Authentication.   Wildcat! only uses session cookies as oppose to persistent cookies which stay on the user's machine when the browser is closed.   Session cookies are not stored the user's machine and automatically destroyed when the browser is closed or when the user's logs off by "clicking" the logout URL or botton in your web pages.

Mixing BASIC/DIGEST Authentication with Cookie Authentication

If you plan to offer cookie authentication, the most important consideration is whether you will continue to offer BASIC and DIGEST authenticaitions methods as well which are the browser  popup box login methods of logging into the web server.

• BASIC/DIGEST authentication uses the Browser Login Popup box,
• Cookie Authenticaiton uses a html login form with userid/passsword fields.

There are two primary considerations to enable BASIC and DIGEST:

• You don't care which method the user logins with, and/or
• To support users who disable session cookies in their browser.

There are three primary considerations to disable BASIC and DIGEST.

• You wish to use cookie-based logins without changing your current web pages, or
• You wish to redesign your web pages around cookie-based login userid/password form fields, and
• You wish to use cookie-based logins as the primary method to login.

If you wish to instantly support cookie authentication without making any changes to your current web pages.  you should turn off (disable) both BASIC and DIGEST Authentication.

The reason is straight forward.

wcWEB will check every web request to a secured (private side) web page or url for proper authorization.  When a request is unauthorized, wcWEB will automatically send the 401 response code (login required) and send UserNotLoggin.wct. If UserNotLoggin.wct is not found, it will send the the default Unauthorized.wct page.

If BASIC/DIGEST is enabled, wcWEB will also the "www-authenticate:" HTTP response header which will force the browser to popup the login box. 

Even though the UserLoggin.wct (or Unauthorized.wct) page was also sent, it is not shown to the user because the browser is busy with the login popup box.

Thus by disabling BASIC/DIGEST, the "www-authenticate:" HTTP response header is not sent and the browser will now display the UserLoggin.wct (or Unauthorized.wct) page providing the opportunity login using cookies.

Another way to see this is when the user bypasses your login page by directly typing an URL to a secured web location, like /client?message.wcn, which goes directly to the message areas.  With BASIC or DIGEST enabled, the web server will unauthorize this access and prompt the browser to login.