W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1996

Re: custom authentication functions

From: Mike Meyer <mwm@contessa.phone.net>
Date: Fri, 29 Mar 1996 10:26:35 PST
Message-Id: <19960329.7A20CD8.99B6@contessa.phone.net>
To: www-talk@w3.org
> > This problem doesn't require a change in CGI. CGI is for more than
> > Unix. Unix systems have to find another solution. Ignoring the problem
> > is one of them.
> Except that CGI is supposed to be server, language, and OS independant,
> yes?

That's the goal. It's clearly not realizable in general. Some
languages/platforms/OSes have to have exceptions to deal with things
that don't exist or they can't do or - in this case - are a security

> Thus, if I say "HTTP_AUTHORIZATION" goes in the environment for
> everything but UNIX, and in UNIX that data gets passed on file handle 12
> (or in shared memory or whatever), then it's going to be very difficult to
> write a CGI script that will work under multiple operating systems,
> especially those that don't refer to file handles with numbers.

Nope. I've got a web server running on a platform that has
case-insensitive environment variable names. I can write CGI scripts
that grab "http_referer" and the like, and they'll work perfectly on
that playtform.  That's a good way to write non-portable scripts, and
the platform-dependent part of the spec recommends that you not do
that.  Similarly, PATH_TRANSLATED isn't always available (I initially
didn't provide it because I couldn't do it reliably; my users wanted
it even after I explained the unreliability issue, so the latest beta
provides it); you can write scripts that depend on PATH_TRANSLATED and
they'll break on some servers. Or you can write scripts that check for
it and deal with it not being set in some sane way.

Same thing here. I dislike the suggestion you've made, because it's
very unix centric. Your idea of a file that's a second argument to the
script with that CGI variable in it is a good one. Possibly allowing
all CGI variables to come in that way would be usefull. A portable
script then checks for that extra argument and if it exists loads it
into an associative array to be checked for variables.

Yes, it's a bit of extra work to write portable code. That's always
been true, and I don't think we're going to change it.

Right now, the problem is that all servers do this DIFFERENTLY; there
is either no way for a CGI script to get that information, or it's
somewhere that's very server dependent. One solution that would work
for as many servers as possible would be a better idea. But it belongs
in CGI/1.2, not 1.1.

> BTW, I think we're in violent agreement here. I would think the proper
> approach is to have a flag in the server (perhaps on a per-script basis)
> that would say whether to pass the authentication information in the
> environment.

This doesn't solve the problem for people who want access to the
authorization data but are on systems with hostile users and a stock
ps. Other solutions do.

Received on Friday, 29 March 1996 13:38:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:58 UTC