- From: Darren New <dnew@sgf.fv.com>
- Date: Fri, 1 Dec 1995 12:09:11 +0000
- To: Pat La Claire <excalib!sparcy!pat@ucsd.edu>
- Cc: Norderhaug.CHI@xerox.com, www-talk@w3.org
#> we're required to have *some* form of access control to our httpd #server. we > require a username/password combination to "login" to our #application. once > login has been authorized, we generate a unique #session key to identify this > user in the system until the user either #logs out or timeouts. the session > key is passed between the forms as a #hidden field. our cgi program embeds > the session key in the next form #served. this way we maintain whatever state > information that we need in #our application (which is a server that the cgi > calls). the application #maintains a "user thread" that contains lots of stuff, > and is keyed off #the session key. > > this access control is by not means bullet proof, but #all we need at this time. Yes, that's how earlier versions of my software worked as well. The problem was invoking the overhead of parsing HTML to find the embedded URLs on each hit when all I really wanted was to know who was accessing which pages. :-) It would be nice if the server could send back an authorization header with the username/password to be used by the client for this realm, but unfortunately, that's not how it was specified. Hence, either the user has to type the stuff into a form that you have no control over the look&feel of (i.e., the authorization pop-up), or you have to embed stuff in the URL. --Darren
Received on Friday, 1 December 1995 12:11:47 UTC