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

Re: custom authentication functions

From: Darren New <dnew@yuan.fv.com>
Date: Fri, 29 Mar 1996 11:02:33 -0800 (PST)
To: Mike Meyer <mwm@contessa.phone.net>
Cc: www-talk@w3.org
Message-Id: <Pine.LNX.3.91.960329105154.3664A-100000@yuan.fv.com>
On Fri, 29 Mar 1996, Mike Meyer wrote:
> 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.

Ick.  It's a hack.  Unfortunately, "stock" UNIX doesn't give you any way 
of passing information securely *except* via files.

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

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

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. 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" and "My volume is so high I'm
dedicating multiple CPUs just to handle it, and I'm sure not going to rent
out space to other people on it."  The cost tradeoff is performance of 
your service meaning having to buy another machine for this application.

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.

I don't mind, personally, writing CGI code that has to get adjusted for
different platforms. 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.  :-) I would hate to see the fact that folks don't have
source to "ps" be the cause of braindamaged specs in HTTP and CGI, neither
of which is supposed to be UNIX-dependant, let alone dependant on what 
version of some system maintenance software you're running.

 Darren New / Dir. of Custom Software Design / First Virtual Holdings Inc.
Anyone can buy and sell information over the internet for real money TODAY!
  http://www.fv.com or info@fv.com  -=|=-  PGP key: finger dnew@yuan.fv.com
      This message brought to you by the letter T, and the number 1.
Received on Friday, 29 March 1996 14:08:35 UTC

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