[9899] in www-talk@info.cern.ch
Re: custom authentication functions
daemon@ATHENA.MIT.EDU (Mike Meyer)
Fri Mar 29 13:49:55 1996
In-Reply-To: <Pine.LNX.3.91.960329084445.87A-100000@yuan.fv.com>
From: mwm@contessa.phone.net (Mike Meyer)
Date: Fri, 29 Mar 1996 10:26:35 PST
To: www-talk@w3.org
Resent-From: 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
risk.
> 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.
<mike
