Re: custom authentication functions

> > 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, that would be nice. And portable. But lots of file I/O overhead.

Not compared to the overhead of starting a CGI in the first place :-(.

> It's just a different cost. A file
> pickuniquename/create/write/close/open/read/close/unlink for every hit
> would seem to be excessive on a server doing millions of hits a day, which
> is my application.

Yup, it's excessive. I think CGI is excessive for that as well. So do
most server vendors - that's why they provide propietary, low-overhead
hooks into the server for doing those things.

I sincerely hope that for most people, only a small fraction of hits
are going to be CGI, and an even smaller fraction are going to need
authentication information other than what CGI pulls out into non-HTTP
variables. In my experience this is true, but that and hoping for it
doesn't make it so.

> The flag at least gives me the choice of trading off
> between worst-case "I have a server whose volume is so low that I host
> users I don't even trust on the same server"

This sounds like a typical ISP to me :-).

> The file name could be passed as HTTP_AUTH_FILE or some such, and it
> would be understood that reading that file would give you the value of
> HTTP_AUTHORIZATION, after which you can delete the file. Then the
> server-configuration flag would chose between passing it directly and
> passing it indirectly.

The server-configuration flag is outside the area of CGI. I think
CGI/1.2 could use a mechanism for passing arbitrary CGI variables via
a "secure" channel if such is needed.

For instance, the current CGI ID defines a missing VARIABLE and a NULL
value for VARIABLE as being identical. We could change that, and tag
one of them to mean that VARIABLE is being passed through a file, and
VARIABLE_FILENAME contains the name of that file.

Possibly some method of actually encrypting the data could be used?

> I don't mind, personally, writing CGI code that has to get adjusted for
> different platforms.

Personally, I'd rather write it to be as portable as possible in the
first place. Then again, I also like to share my scripts between
clients who aren't running the same server or platform.

> I'd just dislike having a spec that makes the cheap
> work-around to a problem caused by braindead OSes to be the only way of
> doing something.

Hmm - rereading the ID, it contains a suggestion that servers that
validate the authorization header should not pass it to the CGI
environment. This would imply that servers that DON'T validate the
authorization header (which pretty much insures the script does)
should pass it into the environment. Said server should have warnings
about this in any case.

	<mike

P.S. to John - I know about wn's solutions. That solves the problem
for your server, just like NSAPI solves it for theirs, etc. My idea is
to find a portable solution. I also intend to participate in the
CGI/1.2 discussion, and will refer back to these discussion then.

Received on Friday, 29 March 1996 15:26:21 UTC