[3534] in WWW Security List Archive
Re: Warning Re: REMOTE_USER
daemon@ATHENA.MIT.EDU (Jeremey Barrett)
Wed Nov 13 21:20:15 1996
Date: Wed, 13 Nov 1996 14:41:26 -0800 (PST)
From: Jeremey Barrett <jeremey@veriweb.com>
To: "mark.e.von.weihe" <mark.e.von.weihe@ac.com>
cc: www-security <www-security@ns2.rutgers.edu>
In-Reply-To: <9611131106.AB0977@notes2.compuserve.com>
Errors-To: owner-www-security@ns2.rutgers.edu
-----BEGIN PGP SIGNED MESSAGE-----
On 13 Nov 1996, mark.e.von.weihe wrote:
> I'm not well versed on the NCSA server, but I have a similar configuration on a
> Netscape Enterprise server. It does basic authentication, and a CGI picks up
> the REMOTE_USER variable from the environment and uses it later. This has been
> working well with the test clients I've connected. Perhaps the NS
> configuration is quite different and doesn't need the host daemen you refered
> to? Am I risking performance and broken connections with this configuration?
>
Some of this may have been said, I have not followed this thread.
REMOTE_USER is given to a CGI by the server when basic authentication is
passed. It is the username entered by the user into the basic authentication
dialog. It has nothing to do with identd checks made as a result of the
IdentityCheck directive, and so is no performance loss. It is the only way
to capture the username given in a basic authentication dialog.
REMOTE_USER will not be present unless basic authentication is required and
was successful.
The IdentityCheck directive tells the server to attempt a query of the
client's identd daemon. Often this daemon is not present. The value, if
found, is returned in REMOTE_IDENT, not REMOTE_USER.
>
> On Mon, 11 Nov 1996, Steff Watkins wrote:
>
> >
> > I have had this problem earlier with the NCSA webserver. However I found
> > that, with the NCSA webserver, I could use the REMOTE_USER environment
> > variable if I configured my webserver with the following parametr in
> > httpd.conf:
> >
> > IdentityCheck On
>
> This is a very bad idea in general. First it is at best a performance
> problem. But worse, many hosts do not run the daemon required to
> respond to the request that results from this configuration option.
> This often results in a (ICMP) response which some TCP/IP implementations
> use to reset ALL connections to/from the host which requested
> the unsupported service. So your webserver can end up with many
> unexpected broken connections.
>
> Dave Morris
>
>
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Jeremey Barrett
Senior Software Engineer jeremey@veriweb.com
VeriWeb Internet Corp. http://www.veriweb.com/
PGP Key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64
PGP Public Key: http://www.veriweb.com/people/jeremey/pgpkey.html
"less is more." -- Mies van de Rohe.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMopOkS/fy+vkqMxNAQHWdwP5Adj2x+xPfmfDtHCu6/TzejBgNPYOjHqw
Ye/2bJ12ryU8smkKLnHk9+0G0kwcRFi9CB3GFcgtrnpl9ovL/VcmfMfw3HXwFOQ/
/uko1DLs2pr1oAOuwPzjLR14d4eyV2zp3C9SMojBwZs25B7q/5niZrjjzy7bZIVN
e29YQejWjys=
=nvN9
-----END PGP SIGNATURE-----
