(per Marco, 2.1.2012)
== Symptoms
Users with 8 character long SUNetIDs can't log into your Drupal site using WebAuth. Other users have no issue.
== Triggers
There is a bug in the WebAuth module for Drupal that's triggered under the following conditions:
* vanity URL is handled by the Reverse Proxy servers
* WMD 2.55 or 2.56 (possibly earlier ones as well)
* SUNetID of person logging in is 8 characters long
== The Cause
A recent change to WebAuth on the WWW's (not the Drupal module but the Apache module) has made WebAuth cookies slightly longer than they used to be. These cookies are what browsers send to the web server to let it know a user is logged in using WebAuth. They are what make it possible for you to log into WebAuth just once.
WMD stores your cookie, encrypted, temporarily to get around some reverse proxy issues. It did this just fine up until recently (early January).
The problem is that the cookies are now longer, and the cookies for 8-character SUNetIDs are slightly longer still. The function used by WMD to encrypt the cookie can only handle data that is a certain length and fails if the data is too long. If it fails, your cookie is not stored, and you can't log in to the Drupal site.
== Fixes
=== Update the private / public key pair so that the WMD function can encrypt longer cookies
This requires changing a file in AFS and updating a variable in the database but it makes no changes to code on your site so it won't break upgrades. If you can't move your vanity URL to the WWWs because you can't upgrade your site right now, this is the way to go. Assuming you are OK with manipulating files and databases, go here for instructions and a new public/private key pair:
https://www.stanford.edu/dept/its/cgi-bin/services/collab/tools/new_key.php
=== Move vanity URL
This isn't something you can do yourself and requires a HelpSU ticket to the web team. If you are using a reverse proxy you should have received a message recently about an upcoming change to your virtual host and what you need to do, so this might be getting fixed soon. Refer to that email for details. The subject should say "Virtual Host: xyz" and be addressed to all the admins of the AFS space.
BTW, you can tell if your site is running on the proxy server by running the following command on one of the corn machines:
host yourvanity.stanford.edu
If you get a response that matches "proxy-service.best.stanford.edu", your vanity URL is on the proxy server. If, instead, it mentions www-lb.stanford.edu, you are not and this bug should not be affecting you.
== Update to WMD 3.x
I would not recommend doing this yet if you are on the collaboration tools installer, as an update to that is forthcoming. Updating manually would break that upgrade. If you are maintaining your site manually though, you could give WMD 3.x a shot (hosted on http://drupalfeatures.stanford.edu/project/webauth)
