Re: custom authentication functions

On Fri, 29 Mar 1996, Mike Meyer wrote:
> Not compared to the overhead of starting a CGI in the first place :-(.

Again, that would depend on how CGIs are implemented. I can easily 
imagine a server implementing Tcl CGIs as simply sourcing and then 
invoking the code in an interpreter, for example.

> I sincerely hope that for most people, only a small fraction of hits
> are going to be CGI,

That's what everyone hopes. That's why CGI has so much overhead. ;-)

Seriously, tho, we have web servers where every single hit is a CGI 
script. That makes the servers that do things like forking off a dozen 
copies of themself useless, since they all exec and die anyway. A better 
solution for *us* would be as I said above.

> 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.

I think as the web gets more commercial, the proper payment headers would 
become more important. I think the real problem is that the standards for 
the new and exciting things are falling far behind what people want to 
do, forcing them to use CGI to implement stuff that the server could be 
doing itself if it were standardized. For example, what would be great 
for me would be a browser that offers Payment: headers and a server that 
logs said Payment: headers, and then I could just write a program to do 
the offline processing. But since that's not standard yet, I have to 
write code and hook it in somehow, and basic authentication is the only 
thing I've found that performs even a little the way I want it to.

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

Typical ISPs don't let their users install CGI.

> 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.

That makes sense to me.

> 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.

I think it would be better to simply say that the presense of 
VARIABLE_FILENAME in the environment indicates that the variable is being 
passed in that file.  Or perhaps that *all* variables are being passed in 
the file whose name is in FILENAME.

Ick ick.

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

Encrypting it and passing it in the environment? Unless you're going to 
public-key encrypt it, and then have an unreadable secret-key file for 
each CGI script, that doesn't solve the problem. Basic authentication is 
*already* encrypted; it's just too easy for someone other than the server 
to decrypt.

> > 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.

That's certainly my *preference*, of course. But I'd rather have to 
adjust code for each platform than to say "You can't do this because we 
can't figure out how to make it both elegant and portable."

> 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.

Um, no. It doesn't really imply that at all. One would think it's a good 
idea, but it doesn't logically follow. :-)  It should be stated clearly 
in the standard if that's the case.

> to find a portable solution. I also intend to participate in the
> CGI/1.2 discussion, and will refer back to these discussion then.

Great!
  --Darren

Received on Friday, 29 March 1996 15:51:57 UTC