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

Re: custom authentication functions

From: Mike Meyer <mwm@contessa.phone.net>
Date: Wed, 27 Mar 1996 10:45:15 PST
Message-Id: <19960327.75DE490.9A38@contessa.phone.net>
To: www-talk@w3.org
> > header. The environment of a Unix process is publicly available on
> > most (all?) unix systems.
> Um, how's that?  I'm pretty sure you have to read /dev/kmem to get the
> environment for someone else's process.  How would you do this?

The "e" flag to ps on BSD-based boxes will give you the environment.
To get it all, you want to use "ww" as well. I don't konw SysV boxes
(which means my "most" was wrong).

> Fortunately, our webservers don't have any untrusted users logging in.
> :-) And it certainly isn't any less secure than dumping the name/passwd
> pairs thru the internet in the "clear".

That depends on who you are trying to protect against, but you're
essentially right. Remember, I'm just the messenger here.

> Actually, for at least the ones I've looked at, it's a pain. It would be
> much easier to special-case taking it out of the environment than it would
> be to write code to find it and insert it into the environment in the
> right place. The real problem is that the CGI script doesn't get invoked
> until *after* the username and password are validated. If you want the CGI
> script to do the validation, you're out of luck.

Your real problem is a DIFFERENT problem than not being able to get
the authentication headers. If you want your CGI script to do
authentication, you need to disable the server authentication. You'll
then have to get the authentication data from the server somehow.

If the server is doing authentication when it's not been configured to
do so, I'd call that a server bug.

> This is falling back to the old ACL/setuid argument. Is it better to have
> the access control built in to a system (like httpd) or is it better to
> give a user program the info it needs to decide whether to permit access?
> Currently, I've not found a browser that will invoke CGIs whose basic
> authentication doesn't match what's in the config files

That's not a browser issue - the browser doesn't have any choice in
the matter. If the server is refusing to let it run the CGIs without
that authentication information, there isn't much the browser can do
about it.

The server should ignore authentication if it's not configured to pay
attention to it. Your CGI script needs to handle the entire
authentication process - including rejecting unauthenticated or
improperly authenticated requests.

Received on Thursday, 28 March 1996 06:31:35 UTC

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