[9890] in www-talk@info.cern.ch
out of office Mar 26-29
daemon@ATHENA.MIT.EDU (Joshy Joseph)
Thu Mar 28 07:13:37 1996
Date: 28 Mar 96 04:05:04 -0800
From: "Joshy Joseph" <JJOSEPH@us.oracle.com>
To: www-talk@w3.org
Reply-To: JJOSEPH@us.oracle.com
Resent-From: www-talk@w3.org
--Boundary-589508-0-0
I will be out attending a conference Mar 26-29. I will read your mail when I
return.
Thanks,
Joshy
--Boundary-589508-0-0
Content-Type: message/rfc822
Date: 28 Mar 96 06:32:58
From:"www-talk-d-request@w3.org" <www-talk-d-request@w3.org>
To:www-talk-d@w3.org
Subject:www-talk-d Digest V96 #30
Reply-to:www-talk@w3.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=Boundary-589508-0-1
--Boundary-589508-0-1
Content-Type: message/rfc822
Date: 28 Mar 96 06:32:58
From:"www-talk-d-request@w3.org" <www-talk-d-request@w3.org>
To:www-talk-d@w3.org
Subject:www-talk-d Digest V96 #30
Reply-to:www-talk@w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
www-talk-d Digest Volume 96 : Issue 30
Today's Topics:
Re: Receiving requests
Re: www-talk-d Digest V96 #29
Survey on WWW Quality of Services
Re: Receiving requests
RE: www-talk-d Digest V96 #29
ISMAP vs browser-generated URL
Re: ISMAP vs browser-generated URL
Re: ISMAP vs browser-generated URL
custom authentication functions
RE: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
Re: custom authentication functions
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_2;
Type = " "
Date: Sun, 24 Mar 1996 13:30:16 -0800 (PST)
From: Simon Spero <ses@tipper.oit.unc.edu>
To: Fabien Petitcolas <fapp2@hermes.cam.ac.uk>
Cc: "'www-talk@w3.org'" <www-talk@w3.org>
Subject: Re: Receiving requests
Message-Id: <Pine.SOL.3.91.960324132704.27765B-100000@chivalry>
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 853
On Sun, 24 Mar 1996, Fabien Petitcolas wrote:
> What is the most common way for receiving requests from a browser?
> I tried to use the following code, but the program stops in the loop.
> What's wrong in this way of doing?
>
>
> while ((nread = recv(socket, buffer, BUFFER_SIZE, 0))>0)
Typical Fenland community college student :-)
The reason your code doesn't work is that you're trying to read
everything up until the end of file, when you really only want to read
until the end of the first line.
Simon
---
They say in online country So which side are you on boys
There is no middle way Which side are you on
You'll either be a Usenet man Which side are you on boys
Or a thug for the CDA Which side are you on?
National Union of Computer Operatives; Hackers, local 37 APL-CPIO
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_3;
Type = " "
Date: Mon, 25 Mar 1996 14:17:29 -0800
From: mlhu@ipv64a.hfcas.ac.cn
To: www-talk@w3.org
Subject: Re: www-talk-d Digest V96 #29
Message-Id: <199603250624.OAA16185@gateway.nic.ustc.ac.cn>
content-length: 36
unsubscribe mlhu@ipv64a.hfcas.ac.cn
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_4;
Type = " "
Date: Mon, 25 Mar 1996 17:26:12 +0000
From: Rui Meneses <rui.meneses@jrc.it>
To: http-mib@onramp.net, desire@surfnet.nl, www-proxy@www10.w3.org,
wg-all@terena.nl, snmp@psi.com, quality-errors@nic.nasa.gov,
wg-isus@rare.nl, www-talk@www0.cern.ch, applmib@emi-summit.com,
rtdnet-forum@terena.nl
Cc: chrisw@iwl.com, cwk@onramp.net, pras@cs.utwente.nl, hazewink@cs.utwente.nl,
mgamble@esys1.esys.co.uk, tchiotis@theseas.softlab.ece.ntua.gr,
pedro.veiga@di.fc.ul.pt, spada@one.it, villa@one.it,
carlos.picoto@di.fc.ul.pt, rui.meneses@jrc.it, pwin@dg13.cec.be
Subject: Survey on WWW Quality of Services
Message-Id: <1.5.4b13.16.19960325172612.34efb3a4@iseics1.jrc.it>
Content-Type: text/plain; charset="us-ascii"
Content-Length: 1742
In the framework of DESIRE, a European-wide project
funded in the Telematics for Research sector of the 4th
Framework Programme of the European Commission, a set
of questionnaires addressing the Quality of Services
delivered by distributed information services (most notably
the WWW) has been placed on line at the following URL:
http://www.netmode.ntua.gr/musiq/
We would appreciate if you could spend a few minutes of
your time filling in the questionnaire that is more adequate
to your profile (User, Provider, Developer).
The processed results may be available to those who will request it in
the forms, although individual contributions will be kept strictly confidential.
We would appreciate if you could diffuse this message to
the widest possible audience, and eventually make a link to
the above URL at your Information Server.
Part of the results may be used in a requirements document
to be used in the preparation of a possible "Web Server
Management MIB", at the IETF.
Any questions regarding this exercise should be sent to
rui.meneses@jrc.it
Thank you in advance for your co-operation,
Rui Meneses
o~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~o
Rui Meneses
Centre for Earth Observation - Data Networks
Institute for Space Applications
Joint Research Centre of the E.C. - TP. 950
Ispra 21020 (VA) Italy
---------------------------------------------------------------------
SMTP : rui.meneses@jrc.it (MIME & BINHEX messages accepted)
X.400 : <C=IT;A=GARR;P=CCRISPRA;O=CEN;S=MENESES;GI=RUI>
Phone : 39+(0)332+785224 Fax : 39+(0)332+785461
o~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~o
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_5;
Type = " "
Date: Mon, 25 Mar 1996 11:05:12 -0500 (EST)
From: Luke Gonze <applix!luke@uunet.uu.net>
To: applix!uunet!w3.org!www-talk@uunet.uu.net
Subject: Re: Receiving requests
Message-Id: <Pine.SUN.3.91.960325110007.4111D-100000@darkness>
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 825
This works for receiving requests from a browser. I haven't tested it in
a real industrial strength situation yet. The first thing you'd need to
improve is to handle requests larger than BUFSIZE.
#define BUFSIZE 10000
int reader(int fd)
{
char buf[BUFSIZE+1];
char *bptr = buf;
int n;
int buflen;
buflen = BUFSIZE;
/* read the string itself */
while( (n = read(fd, bptr, buflen)) > 0){
bptr[n] = '\0';
bptr += n;
buflen -= n;
}
/* if the output of this looks funny, by the way, keep in mind that
^M is ascii 13 */
printf("read from httpd server: \n%s\n",buf);
if( buflen == BUFSIZE )
return(n);
else
return(BUFSIZE - buflen);
}
--- Luke Gonze --- luke@applix.com ---
--- Software Engineer, Applix Espresso project ---
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_6;
Type = " "
Date: Mon, 25 Mar 1996 13:26:03 -0500
From: "Michael A. Browning" <mbrowning@pdltd.com>
To: "www-talk@w3.org" <www-talk@w3.org>
Subject: RE: www-talk-d Digest V96 #29
Message-Id: <c=US%a=_%p=PDLTD.COM%l=MABNTPENTIUM960325132603AB005900@ns1.pdltd.com>
content-length: 690
UNSUBSCRIBE
>----------
>From: www-talk-d-request@w3.org[SMTP:www-talk-d-request@w3.org]
>Sent: Sunday, March 24, 1996 2:56 PM
>To: www-talk-d@w3.org
>Subject: www-talk-d Digest V96 #29
>
><<Message: Microsoft Exchange Message>><<Message: Re: Improve the traffic
>condition on...>><<Message: Restricted software distribution
>via...>><<Message: Re: Improving traffic condition@inet>><<Message: Re:
>Improving traffic condition@inet >><<Message: Re: www-talk-d Digest V96
>#27>><<Message: Re: Improving traffic condition@inet >><<Message: Re:
>Improve the traffic condition on...>><<Message: Re: Improve the traffic
>condition on...>><<Message: ife>><<Message: Receiving requests>>
>
>
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_7;
Type = " "
Date: Tue, 26 Mar 1996 11:17:50 -0500
From: "Daniel Pich\i" <danielp@hp817.speedware.com>
To: www-talk@w3.org
Subject: ISMAP vs browser-generated URL
Message-Id: <315818AE.70E8@speedware.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
content-length: 923
The ISMAP attribute of the IMG element make an image "clickable". When activated, an URL is generated by the WWW
browser and send to the WWW server. Generated URL are not always build the same way! Even using two browsers from
the same provider (netscape for windows and netscape for X-window) do not guaranted an uniform behavior!
Question: Where can I find THE EXACT RULES that govern URL manifacturing.
As example, the netscape browser version for windows append the cursor coordinate to the URL defined in the map
file. The netscape browser version for X-window doesn't react the same, it remplacing the QUERY_STRING portion of
the URL defined in the map file.
So, having defined: default /cgi-bin/program/path_info?query_string
will generate on windows version: /cgi-bin/program/path_info?query_string?x,y
will generate on X-window version: /cgi-bin/program/path_info?x,y
Thank for help. Danielp
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_8;
Type = " "
Date: Tue, 26 Mar 1996 10:17:19 -0700 (MST)
From: Brandon Gillespie <brandon@tombstone.sunrem.com>
To: www-talk@w3.org
Subject: Re: ISMAP vs browser-generated URL
Message-Id: <Pine.BSF.3.91.960326101232.16067A-100000@tombstone.sunrem.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 1631
On Tue, 26 Mar 1996, Daniel Pichi wrote:
> The ISMAP attribute of the IMG element make an image "clickable". When activated, an URL is generated by the WWW
> browser and send to the WWW server. Generated URL are not always build the same way! Even using two browsers from
> the same provider (netscape for windows and netscape for X-window) do not guaranted an uniform behavior!
>
> Question: Where can I find THE EXACT RULES that govern URL manifacturing.
Several sources, for URLs only check out:
ftp://www.ics.uci.edu/pub/ietf/uri/rfc1738.txt
However, I think you are looking for HTTP URLs, for that check out the
HTTP 1.0 specification, specifically section 3.2.2 "HTTP URL"
http://www.w3.org/hypertext/WWW/Protocols/HTTP1.0/draft-ietf-http-spec.html
< As example, the netscape browser version for windows append the cursor
< coordinate to the URL defined in the map file. The netscape browser
< version for X-window doesn't react the same, it remplacing the
< QUERY_STRING portion of the URL defined in the map file.
Suggestion #1: never assume netscape is doing it the standard way, they
likely are not.
< So, having defined: default /cgi-bin/program/path_info?query_string
<
< will generate on windows version: /cgi-bin/program/path_info?query_string?x,y
< will generate on X-window version: /cgi-bin/program/path_info?x,y
From my understanding of HTTP URLs the windows version is wrong, but this
is up for interpretation. From there, it just depends upon how
'path_info' handles its arguments. That they should be standard there is
no doubt; unfortunately they are not.
-Brandon Gillespie-
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_9;
Type = " "
Date: Tue, 26 Mar 1996 09:32:59 -0800
From: chuck@spinnet.com (Chuck Norris)
To: www-talk@w3.org
Cc: "Daniel Pich\i" <danielp@hp817.speedware.com>
Subject: Re: ISMAP vs browser-generated URL
Message-Id: <v02130501ad7dd5c0b599@[134.24.14.29]>
Content-Type: text/plain; charset="us-ascii"
content-length: 2059
Daniel,
The problem is that you are trying to use the query_string portion of the
URL to do more than it was intended. The way imagemap is defined, the
QUERY_STRING component of the URL is reserved for sending only the X,Y
coordinates - you may not use QUERY_STRING to send anything else. The way
around this is to put all of your custom information into PATH_INFO.
Since putting a QUERY_STRING component into the URL explicitly is an error,
it's easy to understand why the Windows and Unix versions of Netscape work
differently - the Unix version checks for this mistake and corrects it,
while the Windows version doesn't.
Hope this helps!
Chuck
>The ISMAP attribute of the IMG element make an image "clickable". When
>activated, an URL is generated by the WWW
>browser and send to the WWW server. Generated URL are not always build the
>same way! Even using two browsers from
>the same provider (netscape for windows and netscape for X-window) do not
>guaranted an uniform behavior!
>
>Question: Where can I find THE EXACT RULES that govern URL manifacturing.
>
>As example, the netscape browser version for windows append the cursor
>coordinate to the URL defined in the map
>file. The netscape browser version for X-window doesn't react the same, it
>remplacing the QUERY_STRING portion of
>the URL defined in the map file.
>
>So, having defined: default /cgi-bin/program/path_info?query_string
>
> will generate on windows version: /cgi-bin/program/path_info?query_string?x,y
> will generate on X-window version: /cgi-bin/program/path_info?x,y
>
>Thank for help. Danielp
------------------------------------------------------------------------------
| email: chuck@spinnet.com
Spinnet Inc. | WWW: http://www.spinnet.com/
Bringing Business to the Internet | phone: (619) 530-0583
| FAX: (619) 530-0276
------------------------------------------------------------------------------
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_10;
Type = " "
Date: Tue, 26 Mar 96 12:49:05 EST
From: hgoldber@nedhmail.nedh.harvard.edu
To: www-talk@w3.org
Subject: custom authentication functions
Message-Id: <9602268278.AA827873677@nedhmail.nedh.harvard.edu>
content-length: 246
I'd like to authenticate users of certain web services as members of a
windows nt domain. Has anyone written or seen a reference to a cgi or
nsapi function to do this? All pointers appreciated.
Howard Goldberg
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_11;
Type = " "
Date: Tue, 26 Mar 1996 14:58:31 -0500
From: "Holub, Jebel" <JHolub@admin.usf.edu>
To: "www-talk@w3.org" <www-talk@w3.org>,
"'hgoldber@nedhmail.nedh.harvard.edu'" <hgoldber@nedhmail.nedh.harvard.edu>
Subject: RE: custom authentication functions
Message-Id: <c=US%a=_%p=USF%l=RMIT960326145831GH006700@rmit.rmit.usf.edu>
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BB1B24.C4044F50"
content-length: 1624
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible. Contact your
mail administrator for information about upgrading your reader to a version
that supports MIME.
------ =_NextPart_000_01BB1B24.C4044F50
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
>----------
>From:
> hgoldber@nedhmail.nedh.harvard.edu[SMTP:hgoldber@nedhmail.nedh.harvard.edu]
>
>Sent: Tuesday, March 26, 1996 12:49 PM
>To: www-talk@w3.org
>Subject: custom authentication functions
>
>
> I'd like to authenticate users of certain web services as members of a
>
> windows nt domain. Has anyone written or seen a reference to a cgi or
>
> nsapi function to do this? All pointers appreciated.
>
>
> I'd like to authenticate users of certain web services as members of a
>
> windows nt domain. Has anyone written or seen a reference to a cgi or
>
> nsapi function to do this? All pointers appreciated.
----As much as I hate to pitch Microsoft, the very feature you're
looking for is built in to Microsoft's Internet Information Server. If you
wish to authenticate users by their domain ID's, the IIS should be loaded on
one of the domain controllers containing the pool of users you wish to
authenticate. Additional authentication features are available with the
ISAPI. Check it out.
Best,
>Jeb
>
>Jeb Holub
>Information Technologies
>University of South Florida
>
>internet: jholub@admin.usf.edu
>httpd: http://voltaire.rmit.usf.edu/
>
>
>
>
------ =_NextPart_000_01BB1B24.C4044F50--
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_12;
Type = " "
Date: Tue, 26 Mar 1996 05:07:49 -0800
From: George Phillips <phillips@nsg.bc.ca>
To: hgoldber@nedhmail.nedh.harvard.edu
Cc: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <199603261307.FAA01133@penelope.nsg.bc.ca>
Content-Type: text/plain; charset=us-ascii
content-length: 605
I've written CGI scripts which do Basic level authentication. The only
catch is that servers seem to keep HTTP_AUTHENTICATE to themselves and
not pass the variable on to the script, even if the server is not doing
authentication on that URL space. That was only under NCSA 1.3 and 1.5;
other servers may handle that correctly. They should be passing the
information on, but I'd guess that so few people tried to do authentication
under CGI that it was never noticed.
Otherwise, the rest is just a matter of following the HTTP protocol and
knowing how to decode the user:password string.
-- George
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_13;
Type = " "
Date: Tue, 26 Mar 1996 20:40:17 PST
From: mwm@contessa.phone.net (Mike Meyer)
To: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <19960326.75B3598.12606@contessa.phone.net>
content-length: 1043
> I've written CGI scripts which do Basic level authentication. The only
> catch is that servers seem to keep HTTP_AUTHENTICATE to themselves and
> not pass the variable on to the script, even if the server is not doing
> authentication on that URL space.
Unix servers that pretend to be secure SHOULD NOT pass authentication
headers to CGI scripts via the environment. The username and password
are trivially extracted from the contents of a basic authentication
header. The environment of a Unix process is publicly available on
most (all?) unix systems. Putting the authentication header in the
environment lets other users of your Unix system grab
username/password pairs if they want them.
There doesn't seem to be a consensus on how this information is passed
to CGI scripts in a secure manner; check your server docs to see what
they did. If you really want to do this and source is available, it's
probably pretty simple to find the code that prevents authentication
headers from going into the environment and disable it.
<mike
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_14;
Type = " "
Date: Wed, 27 Mar 1996 09:54:51 -0500
From: Paul Everitt <paul@digicool.com>
To: hgoldber@nedhmail.nedh.harvard.edu
Cc: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <315956BB.4B8@digicool.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
content-length: 1112
We have a server extension system to replace CGI with an object
interface:
http://www.w3.org/pub/WWW/TR/WD-ilu-requestor.html
It masks the differences between the different APIs, and gives you a
common distributed object interface using ILU.
One of our interfaces is an Authorizer, which passes requests to a
published object to see if the operation is allowed. This published
object can encapsulate NIS, mSQL, or an in-memory object system as the
user database.
In your case, you could publish your Authorizer on NT, and implement it
using the VC++ calls into the NT ACL system. Then, your Unix httpd's
(or Netsite on NT, or IIS on NT) could use NT as the user database.
Because connections are always open with our CGI replacement,
performance should be pretty good.
Our Authorizer is only a first attempt at a simple solution to a complex
problem, so more thought needs to go into the security issues. But
perhaps it would be of value to you.
BTW, all our stuff is publically available (read: free).
--Paul
--
Paul Everitt Digital Creations
paul@digicool.com 540.371.6909
"."
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_15;
Type = " "
Date: Wed, 27 Mar 1996 09:34:59 -0800 (PST)
From: Darren New <dnew@yuan.fv.com>
To: Mike Meyer <mwm@contessa.phone.net>
Cc: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <Pine.LNX.3.91.960327092714.351A-100000@yuan.fv.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 2062
On Tue, 26 Mar 1996, Mike Meyer wrote:
> 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?
> Putting the authentication header in the
> environment lets other users of your Unix system grab
> username/password pairs if they want them.
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".
> they did. If you really want to do this and source is available, it's
> probably pretty simple to find the code that prevents authentication
> headers from going into the environment and disable it.
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.
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, so you're stuck
with what's compiled into the server. I imagine other servers give you
different APIs for intercepts at different places, but I havent looked
too closely at them yet.
--
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.
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_16;
Type = " "
Date: Wed, 27 Mar 1996 10:48:14 -0800
From: "Daniel L. Smith" <dls@sushi>
To: dnew@fv.com
Cc: Mike Meyer <mwm@contessa.phone.net>, www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <9603271848.AA01288@sushi.aolproductions.com sushi>
content-length: 544
>On Tue, 26 Mar 1996, Mike Meyer wrote:
>> 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?
man ps(1). bsd: ps auxewww will show quite a bit....
sysV: ps -elgwwa
Daniel
Daniel L Smith www.JavaJoint.com
dls@wais.com dls@JavaJoint.com P.O. 613, Sausalito, CA, 94966
Mammal, Husband, Father, Webhead, Prankster, Coffee Addict
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_17;
Type = " "
Date: Wed, 27 Mar 1996 11:49:56 -0800
From: "Marc Salomon" <marc@matahari.ckm.ucsf.edu>
To: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <9603271149.ZM16004@matahari.ckm.ucsf.edu>
Content-Type: text/plain; charset=us-ascii
content-length: 2284
Some issues that need to be addressed with www authentication seem to cross
paths here. First, there needs to be a scheme where users can authenticate on
a web server using account information valid for other services (such as telnet
or ppp) on that machine. It would be nice to share big passwd databases
between the web and existing systems, but there seem to be differences in
crypt()s (according to the folks at NCSA) across platforms, both client and
server.
Second, there needs to be some way for a CGI process (or any server-side
application) to have access to protocol-level authentication date so that it
can take steps such as passing those data to external servers (Z39.50, namely)
to gain authorization there. On some dedicated systems functioning as www
servers, random users reading environment variables are not really a serious
security issue. Doing this through forms is hoky.
In the end, this is a server implementation issue, and paternalistic concerns
about security risks in certain configurations should not obviate informed
consent. On the toy platforms this is probably less of a problem than on unix
boxes.
Application-level authentication checking can be done fairly securely in a
modular server, but the standard (for now) is CGI. Also, concerns about random
users viewing env's of other processes with a full ps listing is important but
not always applicable. Its even more of a danger in certain configurations
than snarfing authentication over the wire, because there is no effort involved
in running ps as there is in sniffing data packets.
Lastly, not all authentication schemes are based on the login/passwd model.
Some only have a single cryptic password. It would be cool to specify the
number of authentication terms required for a custom scheme so that users are
not confused by being prompted with boxes they should ignore.
-marc
--
--/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
// Marc Salomon - Software Engineer - Innovative Software Systems Group \\
\\ Library and Center for Knowledge Management - UC, San Francisco //
// phone : 415.476.9541 - e-mail : marc@ckm.ucsf.edu - fax: 415.476.4653 \\
\\/\/\/\/\/\/\/\/\/\/\<URL:http://www.ckm.ucsf.edu/marc/>/\/\/\/\/\/\/\/\/\///
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_18;
Type = " "
Date: Wed, 27 Mar 1996 12:07:44 -0800 (PST)
From: Darren New <dnew@yuan.fv.com>
To: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <Pine.LNX.3.91.960327120637.1508A-100000@yuan.fv.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 693
On Wed, 27 Mar 1996, Daniel L. Smith wrote:
> >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?
>
> man ps(1). bsd: ps auxewww will show quite a bit....
> sysV: ps -elgwwa
Like I said.... you have to have access to /dev/kmem. ;-)
Followups to me, please. This is getting off the WWW track.
--
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.
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_19;
Type = " "
Date: Wed, 27 Mar 1996 12:10:20 -0800 (PST)
From: Darren New <dnew@yuan.fv.com>
To: marc@ckm.ucsf.edu
Cc: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <Pine.LNX.3.91.960327120829.1508B-100000@yuan.fv.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 1001
On Wed, 27 Mar 1996, Marc Salomon wrote:
> Lastly, not all authentication schemes are based on the login/passwd model.
> Some only have a single cryptic password. It would be cool to specify the
> number of authentication terms required for a custom scheme so that users are
> not confused by being prompted with boxes they should ignore.
I agree. The ideal would be to provide a realm, a title of some sort, and
a list of prompts to take in values. "Basic" would then default to the
prompts of username and password with a title "Basic authentication" or
some such. The ability to configure some realms in the system as going
thru CGI and others being done more efficiently would also be good.
--
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.
--Boundary-589508-0-1
Content-Type: text/plain; charset=us-ascii;
Name = attachment_20;
Type = " "
Date: Wed, 27 Mar 1996 10:45:15 PST
From: mwm@contessa.phone.net (Mike Meyer)
To: www-talk@w3.org
Subject: Re: custom authentication functions
Message-Id: <19960327.75DE490.9A38@contessa.phone.net>
content-length: 2344
> > 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.
<mike
--Boundary-589508-0-1--
--Boundary-589508-0-0--
