Date: Fri, 6 Feb 1998 17:39:05 +1300 From: andrew@squiz.co.nz (Andrew McNaughton) To: hackers@FreeBSD.ORG Subject: RE: WebAdmin Message-ID: <v02120d00b0ff5030c15f@[203.96.56.128]>
next in thread | raw e-mail | index | archive | help
Adrian Chadd <adrian@obiwan.creative.net.au> wrote: > >On Mon, 2 Feb 1998, Adam Turoff wrote: > >> Standardizing on HTTP as a client/server interface between multiple >> clients has a lot of possibilities. First, we start with a well defined >> API >> to write the server side bits (the admin component subset will require >> more structure than generic CGI), and the client side starts out with >> a well defined API that's mostly implemented in almost any language >> today. >> >> However, I'm concerned that HTTP 1.0 is a stateless protocol, and that >> it's pretty much nothing more than a NFS with remote execution. HTTP >> 1.1, >> once everything supports it sufficiently, will handle the stateless part >> with >> keep-alive that actually works. >> > >Depends. ><INPUT TYPE="HIDDEN"> ? > >I've written a couple of web-based SQL databases, and I have been able >to sucessfully encode enough state into the webpages themselves to make >the databases useable and stable. I'm new to FreeBSD, but I've spent the past year doing CGI programming, including a system for administering a database of users (not users in the sense of being in /etc/passwd though). The first time I wrote an authentication system, I used a hidden session key as suggested above. It's messy, mostly because it gets lost any time the user visits a static page as tends to happen when they go to look at some documentation. If users are encouraged (or even allowed) to back up using the browser's back button, then problems occur with form data being resubmitted in order to view a page again. It's somewhat browser dependent. To prevent this, session keys should probably be changed whenever data is submitted, though I haven't yet implemented this. It's also likely that hidden variables in pages will wind up being cached somewhere, in spite of any attempts to prevent it. Sessions must expire on the server. I currently use Netscape cookies to store session keys, which simplifies the above problem. I keep session records on the server which (if the user is logged in) refer to the appropriate user records. They also store the IP associated with the connection, and the time when the session key was last used. This works well enough. The Perl CPAN module CGI::MiniSvr implements another approach. This is from it's documentation: > This file implements the CGI::MiniSvr object. This object represents an > alternative interface between the application and an HTTP deamon. > > In a typical CGI scenario the interface is just a collection of environment > variables passed to a process which then generated some outout and exits. > The CGI::Base class implements this standard interface. > > The CGI::MiniSvr class inherits from CGI::Base and extends it to implement > a 'mini http daemon' which can be spawned (forked) from a CGI script in > order to maintain state information for a client 'session'. > > This is very useful. It neatly side-steps many of the painful issues involved > in writing real-world multi-screen applications using the standard CGI > interface (namely saving and restoring state between screens). The httpd on port 80 refers the browser to the newly forked http mini-server operating on a new port. This mini-server serves only one user and maintains state in memory from one request to the next. There are of course still authentication issues which must be dealt with on every request. SSL or similar would be required in order to safeguard passwords. Storing the IP associated with requests helps to avoid hijack, but is open to spoofing attacks from anyone able to intercept packets containing the session ID. The effort to understand the universe is Andrew McNaughton one of the very few things that lifts ++64 4 389 6891 human life above the level of farce, andrew@squiz.co.nz and gives it some of the grace http://www.squiz.co.nz of tragedy - Steven Weinberg http://www.newsroom.co.nz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02120d00b0ff5030c15f>