W3C home > Mailing lists > Public > www-talk@w3.org > May to June 2000

RE: cgi authorization

From: Fish <fish@infidels.org>
Date: Tue, 20 Jun 2000 16:30:42 -0700
To: "Whyard, Matthew" <Matthew.Whyard@siemenscomms.co.uk>
Cc: <www-talk@w3.org>
Message-ID: <000001bfdb0f$8cff57c0$0200a8c0@PROTEVA>
This is the first message to this email list I've seen that I could answer
myself -- sort of. :)

What is it with this list anyway? I thought it would be quite active, with
messages flying back and forth from developers all over the world, but
apparently not. In the several months I've been subscribed to this email list, I
think I've seen maybe 6 messages, and all of them from people asking for help
with NO ONE ever responding.

Personally, I think this email list is pretty useless myself. Still, I remain
subscribed to it in the hope that perhaps this will, over time, change. :)

(Note to those replying to questions posted to this list: PLEASE use "reply all"
(and not just "reply") so a copy gets sent to the list in addition to the person
that asked the question. The rest of us would like to learn what the answer is
too you know!)

====================================================

Hi Matt!

According to RFC2616 ("Hypertext Transfer Protocol -- HTTP/1.1"):

----------------------------------------------------

[...]

10.4.2 401 Unauthorized

   The request requires user authentication. The response MUST include a
   WWW-Authenticate header field (section 14.47) containing a challenge
   applicable to the requested resource. The client MAY repeat the
   request with a suitable Authorization header field (section 14.8). If
   the request already included Authorization credentials, then the 401
   response indicates that authorization has been refused for those
   credentials. If the 401 response contains the same challenge as the
   prior response, and the user agent has already attempted
   authentication at least once, then the user SHOULD be presented the
   entity that was given in the response, since that entity might
   include relevant diagnostic information. HTTP access authentication
   is explained in "HTTP Authentication: Basic and Digest Access
   Authentication" [43].

[...]

14.47 WWW-Authenticate

   The WWW-Authenticate response-header field MUST be included in 401
   (Unauthorized) response messages. The field value consists of at
   least one challenge that indicates the authentication scheme(s) and
   parameters applicable to the Request-URI.

       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

   The HTTP access authentication process is described in "HTTP
   Authentication: Basic and Digest Access Authentication" [43]. User
   agents are advised to take special care in parsing the WWW-
   Authenticate field value as it might contain more than one challenge,
   or if more than one WWW-Authenticate header field is provided, the
   contents of a challenge itself can contain a comma-separated list of
   authentication parameters.

[...]

[14.8 Authorization

      A user agent that wishes to authenticate itself with a server--
      usually, but not necessarily, after receiving a 401 response--does
      so by including an Authorization request-header field with the
      request.  The Authorization field value consists of credentials
      containing the authentication information of the user agent for
      the realm of the resource being requested.

          Authorization  = "Authorization" ":" credentials

      HTTP access authentication is described in "HTTP Authentication:
      Basic and Digest Access Authentication" [43]. If a request is
      authenticated and a realm specified, the same credentials SHOULD
      be valid for all other requests within this realm (assuming that
      the authentication scheme itself does not require otherwise, such
      as credentials that vary according to a challenge value or using
      synchronized clocks).

      When a shared cache (see section 13.7) receives a request
      containing an Authorization field, it MUST NOT return the
      corresponding response as a reply to any other request, unless one
      of the following specific exceptions holds:

      1. If the response includes the "s-maxage" cache-control
         directive, the cache MAY use that response in replying to a
         subsequent request. But (if the specified maximum age has
         passed) a proxy cache MUST first revalidate it with the origin
         server, using the request-headers from the new request to allow
         the origin server to authenticate the new request. (This is the
         defined behavior for s-maxage.) If the response includes "s-
         maxage=0", the proxy MUST always revalidate it before re-using
         it.

      2. If the response includes the "must-revalidate" cache-control
         directive, the cache MAY use that response in replying to a
         subsequent request. But if the response is stale, all caches
         MUST first revalidate it with the origin server, using the
         request-headers from the new request to allow the origin server
         to authenticate the new request.

      3. If the response includes the "public" cache-control directive,
         it MAY be returned in reply to any subsequent request.

-----------------------------------------------------


Apparently, according to RFC2616, the 401 response you received should have
included a "WWW-Authenticate:" header. This header contains the challenge. The
response to the challenge would, it seems, be entered in the "Authorization:"
header on a subsequent request.

The details to the challenge-response authentication method is apparently
described in RFC2617 ("HTTP Authentication: Basic and Digest Access
Authentication").

Good luck!


  "Fish" (David B. Trout)
     fish@infidels.org
       ICQ# 25302291




> -----Original Message-----
> From: www-talk-request@w3.org [mailto:www-talk-request@w3.org]On Behalf
> Of Whyard, Matthew
> Sent: Friday, June 16, 2000 2:53 am
> To: 'www-talk@w3.org'
> Subject: cgi authorization
>
>
> I am writing a Perl CGI script for checking the validity of URLs which
> reference documents on an Intranet. The users authorize themselves by
> entering a username/password in a standard browser prompt, in order to
> access the Intranet.
>
> When entering the URL in a form, on sumbitting it the CGI script uses
> sockets to send an HTTP HEAD request to the server for the referenced
> document. However, many of the documents require a 'different'
> authorization, although the username and password already entered to access
> the Intranet is usually fine to access the document. What is basically
> happening is that the response received from the server is a "401
> authorization required".... what I need is a way of passing the username
> (simple) and password (how??!) already entered with the HEAD request for the
> document.
>
> I would really appreciate some help!
> Matt
Received on Tuesday, 20 June 2000 19:30:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:24 GMT