Re: CGI/1.0: last call
jern@spaceaix.jhuapl.edu
From: jern@spaceaix.jhuapl.edu
Message-id: <9312061913.AA18055@sdrmis.jhuapl.edu>
Subject: Re: CGI/1.0: last call
To: www-talk@nxoc01.cern.ch
Date: Mon, 6 Dec 1993 14:13:51 -0500 (EST)
Cc: sanders@bsdi.com
In-reply-to: <199312061758.LAA05294@austin.BSDI.COM> from "Tony Sanders" at Dec 6, 93 11:58:41 am
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1363
sanders@BSDI.COM writes:>
> bobj <jern@spaceaix.jhuapl.edu> writes:
> > Authentication must be the responsibility of the script writer. While
>
> Authentication must be the responsibility of the server. If you want to
> easily extend the possible authentication schemes then define a spec for
> authentication scripts, but they should remain seperate from normal scripts,
> which should not have to deal with authentication, that would be a HUGE
> security hole.
Of course this is right. In the context of the original message,
passwords for accessing Oracle were the question but my response to
that used language that was too general. To try to put my comment
in context, assuming that the incoming query has traversed the network,
gained access to the machine, is granted access to the scripts and is
attempting to access an Oracle database, the *Oracle authentication*
is the responsibility of the person writing the Oracle access script. It
would seem unreasonable to pass Oracle authentication requirements up
a layer or two into httpd. It could be done but then httpd would
end up with and application/authentication-scheme token for each
application requiring authentication. Ne c'est pas?
I merely propose that application be done without:
1. a user:password token
2. an application/authentication-scheme in the www server daemon.
bobj