hi all www.wgsn.com is a subscription based service that doesn't use cookies for authentication. we use basic auth.
I would like to share what i consider "how not to implement cookie-free authentication". there are three tiers to our website tier 1 is apache with mod_perl doing authentication and mod_proxy passing requests to tier 2 tier 2 is a content management server tier 3 is the database server. tier 3 stores the raw content, tier 2 puts the bits from the db server together and tier 1 logs the hit and sends it to the client, nothing too fancy here. our authentication has two main bits that suck. first is subscribers have their username and password mapped to a special username and password for the content management systems, which differs on varying levels of subscriptions. as an example, the apache servers may recognize n valid usernames and passwords, while the cms only recognizes 3. this mapping is done via an apache module written in perl, which talks to a series of perl scripts that keep a copy of the user database. when a request comes in to the apache servers, the module maps the customer username/pass to the content management username/pass, rewrites the Authorization: header, and mod_proxy sends the request to tier 2. this sounds reasonably simple, but in the real world it's one big bit of mush of unpleasant stuff that falls over every other week. why that is i've never been able to exactly put my finger on, but i have a feeling it was developers letting their personal preferences getting in the way of business needs, by ignoring existing standards or best practices, and going out to re-invent a better wheel. the second (and imo bigger) bit that sucks is because we do silly things like re-writing incoming http headers and cleaning them as the response goes back out, we can't utilize things like caching as effectively as we could if we were using cookies. the reason for this is due to our requirement that we must see which users are accessing which areas of the site (so we can see what's popular etc). The information we require is stored in these re-written headers. This means we need our downstream caching hierarchy (which is a 3rd party) to send at least an If-Modified-Since request for images (some of which we allow to be cached), and we cannot allow them to cache our html documents. If we used cookies our caches could authenticate & log hits at the caching server nearest the client instead of having to come back to our origin servers for every single hit. in busy periods we serve around 2.5 million objects a day, nothing really major, but enough to make things like this a significant drain on our resources (which are limited as always :) for the reasons above, we are investigating the transition to cookie based authentication. i suppose it really depends on what you are developing, but take heed. i fully understand why cookie based authentication may be unacceptable, but consider maintainability and (long-term) scalability when you're doing your design and implementation. in the end you'll save someone a few grey hairs :) -pete > -----Original Message----- > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 12, 2002 1:44 PM > To: Ron Savage > Cc: Apache mod_perl > Subject: Cookie-free authentication > > > > > Ron Savage wrote: > > On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote: > > > [snip] > > > > Some of us are trying to implement > authentication/login/logout where, > > if at all possible, cookies are not to be used. A cookie-free > > discussion would be most welcome. > > I've done a bit of preliminary work with using Digest > authentication to accomplish this - > see Session.pm in Apache::AuthDigest, the latest copy of > which can be found here > > http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDiges > t-0.022.tar.gz > > it's fairly new interface, and I've only toyed with it > (though there is _some_ > documentation :). however, it seems to me that (for clients > that can support this > implementation of Digest, which seems to be just about > everyone but MSIE) the nonce > provides exactly the kind of state information that is > required for login/logout > authentication. > > of course, it trades cookies for that pop-up box (again), so > if you're looking for > cookiless, HTML form based logins, then it's probably not > what you want. > > --Geoff >
