How
Web Crossing Recognizes Users at Login
Using External Authorization
How Web Crossing Tracks Users Through the Site
Banning and Blocking Troublesome Users
Troubleshooting
Resources
How Web Crossing Recognizes Users at Login
Default
Authorization
Normally, when a user sends a login request, Web Crossing checks
its internal database of userIDs and user passwords, and decides
if the combination is correct. If it is, a user
certificate is created and the user is given access to the site.
HTTP
Basic Authorization
Web servers can restrict access to certain pages and require
users to enter a login name and password. This is referred to as
"HTTP Basic Authentication." Web Crossing can use a web server's
HTTP authentication system instead of its default authentication
system. If you password-protect the directory where the Web Crossing
script is, the server will ask the browser for the user's identity
when the request is made for a page in that directory.
This approach is useful only in an environment when Web Crossing
runs as a CGI, and you don't plan to allow guest access.
The browser gives the user a userID and password window, the user provides the information, and then if the information is correct, the server sends Web Crossing the message that the user is OK to let into the site, and Web Crossing serves up the page.
If the user is not already in Web Crossing's database, a record is added for that user name and password combination. However, the user's email address is not added, because that property is not supported by HTTP basic authorization. You, or they, will have to add it in Preferences.
You can go in as Sysop and pre-register one user or multiple users with names and email addresses (Control Panel > User Management > Add user), or add an email address to a preexisting user, by using Control Panel > User Management > Set a user's preferences. If you don't do this, the users' email address will not be available on the conference pages.
To turn on browser authentication, go to the Control Panel > User Management > Registered Users and find the section on HTTP Basic Authorization.
Figure 1 - HTTP Basic Authentication Pane
| Note: Guest access is not possible under HTTP Basic Authorization, and users will not be able to register themselves for Web Crossing without any action on your part: you will have to set up and maintain the server-based authorization system. |
External authorization refers to a procedure whereby some external source validates a user and tells Web Crossing that it's OK to admit them. If the user doesn't exist in the Web Crossing database, you can instruct Web Crossing to automatically register them. If you're using a Radius server for authentication, you can set Web Crossing to interface with the Radius server in Control Panel > Registered Users.
If you want to use another form of external authorization, you'll need to set up an authenticate filter macro. This permits you to intercept an unauthenticated user's first access to Web Crossing and query an external database via a script you call with the WCTL %% exec %% directive, to get the information from your external database and determine whether the user should be logged in. The script will have to be written in some programming language that your web server understands. For more information on this, see the Web Crossing FAQ.
One strategy is to have your external authorization system set a cookie after it authorizes the users. Web Crossing then reads the cookie and allows entry. An example of how to do this is in the authfiltex.tpl, which you can find on the Web Crossing FTP server.
(ftp://ftp.webcrossing.com).Another strategy is to have your external authorization system send Web Crossing the userID information in an URL. An example of this is in the authenticateFilterSample macro in the useful.tpl file, which you can find in your Web Crossing server directory. See the sysop docs for more information on how to pass variables in an URL.
A third way to go about it is to set up external authorization via XML-RPC. The basic strategy would be to have Web Crossing check for authorization, and if the user is listed, admit them. Then you can have Web Crossing add the user if they aren't already in the Web Crossing database.
How Web Crossing Tracks Users Through the Site
Certificate-based authorization is the default method used by Web Crossing. The unique user certificate, created each time upon login, follows the user throughout the site as he or she clicks on Web Crossing-generated links, and identifies him or her to Web Crossing.
Login
certificates expire when the user hasn't requested any pages for a chosen length
of time. This time is configurable on a site-wide default basis by the sysop
in the Control Panel > General Settings > Automated
Logout, or for any individual user on his or her preferences page.
Note: If you are using certificate-based authorization and have content on your site which requires the user to step out of the Web Crossing-served content area and then back in, you'll be better off using cookies (described just below) for authentication. In this situation the user certificate will be lost as the user leaves the Web Crossing-served pages and he or she will be asked to log in again upon return. Using cookies prevents this. |
Cookie-based authorization can also be used to keep track of logged-in users. Cookies are tiny text files which Web Crossing places on the user's computer and which are sent back to the server to identify the user when a page is requested.
Web Crossing sets the cookie initially at login, and on subsequent requests for pages the user is identified without having to log in again. The cookie expires when the user quits their browser.
|
Note: If you're using Web Crossing in an environment with shared computers, users will need to be careful to quit their browsers when they are done at your site in order to expire the cookie, so Web Crossing doesn't identify them as someone else mistakenly. You may want to develop a Logout link or button, using the logout macro in the useful.tpl file in your webxTemplates directory on the server, or use the logout cookie macro there, which automatically purges the cookie after a user-definable time. Another strategy is to turn on cookies, but set the defaults for all current and future users to "do not use cookies." That way individual users can turn on cookie use for themselves in Preferences if they wish, but those in shared environments don't have to worry about logging out or quitting their browser. |
When you enable cookies for the site, users will have a choice to enable or disable cookies for themselves individually on their preferences pages. You can choose to enable cookies by default for existing users, and/or enable cookies by default for new users. You can also choose the domain you want the cookie to be served by.
This is useful if you have a site with several sub-domains. For example, if your Web Crossing is hosted on forums.webxharbor.com and your static pages are on pages.webxharbor.com, a cookie set by forums.webxharbor.com wouldn't be readable by pages.webxharbor.com.
But putting in webxharbor.com into the Domain for cookies blank will allow your Web Crossing-set cookie to be read anywhere on the webxharbor.com site.
Figure 3 - Turning on cookies
Passwords In this pane you can also specify whether you want passwords to be case-sensitive or not. It's checked by default, but you'll probably get fewer lost password requests if you disable this option!
Rotating Proxy Servers When a request for a page is made, Web Crossing automatically checks to see whether the user's certificate comes from the same IP address as it did at login. If it's not the same, Web Crossing asks the user to log in again as a security measure.
Most users who are using modems for internet connections will be assigned an IP address when they first dial online, and they will keep this number until they hang up and sign off that particular session. Users who have cable modems or other always-on internet connections will usually have a constant IP address, or one which changes only every several hours.
However, AOL, WebTV, and some other ISPs use rotating proxy servers, meaning that a user may have a different IP address each time they request a page. This may cause these users to have to log in every time they want to go from page to page.
Web Crossing automatically suppresses IP address checking for AOL users, no matter what your settings are for the site. (But it doesn't automatically do this for WebTV users or other ISPs who do this.)
You can turn off IP address checking for individual users through the Control Panel > User management > Set a user's preferences panel.
If you have a lot of users coming from rotating proxy servers, you may want to disable this altogether. However, if you disable it, users do not have the option to enable it individually in preferences.
Issues with certificates and links It's possible for Web Crossing to misidentify a user under certain conditions. The following conditions make it more likely that this will happen:
If the cookie doesn't identify you properly, and you have IP address checking turned off, it's possible for Web Crossing to identify the user as you, via the certificate in the pasted URL! Login certificates expire after 60 minutes (unless you've changed the default in Control Panel > General > Site Information), so there's a limited time window in which this can happen, but the best fix is to always remove the user certificates from links you create manually.
Banning and Blocking Troublesome Users
Sometimes you need to block a user from your forum. There are several approaches you can take:
Some of my users are being asked to log in again and again.
Sysop Documentation
Sysop Control Panel
Web Crossing FAQ: