curl-library
Re: Caching the digest response and using it in subsequent request ...
Date: Tue, 18 May 2010 14:47:29 +0530
>
> Hi There,
>
> this is the snippet from wikipage .... caching is described in the last
> paragraph
> would caching be possible with libcurl, if yes how can this be achieved?
>
> The following example was originally given in RFC 2617<http://tools.ietf.org/html/rfc2617>and is expanded here to show the full text expected for each request and
> response. Note that only the "auth" (authentication) quality of protection
> code is covered – at the time of writing only the Opera<http://en.wikipedia.org/wiki/Opera_(web_browser)>and
> Konqueror <http://en.wikipedia.org/wiki/Konqueror> web browsers<http://en.wikipedia.org/wiki/Web_browser>are known to support "auth-int" (authentication with integrity protection).
> Although the specification mentions HTTP version 1.1 the scheme can be
> successfully added to a version 1.0 server, as shown here.
>
> This typical transaction consists of the following steps.
>
> - The client asks for a page that requires authentication but does not
> provide a user name <http://en.wikipedia.org/wiki/User_name> and
> password. Typically this is because the user simply entered the address or
> followed a link <http://en.wikipedia.org/wiki/Hyperlink> to the page.
> - The server responds with the 401<http://en.wikipedia.org/wiki/HTTP_401#4xx_Client_Error>response code, providing the authentication realm and a randomly-generated,
> single-use value called a nonce<http://en.wikipedia.org/wiki/Cryptographic_nonce>
> .
> - At this point, the client will present the authentication realm
> (typically a description of the computer or system being accessed) to the
> user and prompt for a user name and password. The user may decide to cancel
> at this point.
> - Once a user name and password have been supplied, the client re-sends
> the same request but adds an authentication header that includes the
> response code.
> - In this example, the server accepts the authentication and the page
> is returned. If the user name is invalid and/or the password is incorrect,
> the server might return the "401" response code and the client would prompt
> the user again.
>
> Note: A client may already have the required user name and password without
> needing to prompt the user, e.g. if they have previously been stored by a
> web browser.
> ------------------------------
>
> *Client request (no authentication)*:
>
> GET /dir/index.html HTTP/1.0
> Host: localhost
>
> (followed by a new line <http://en.wikipedia.org/wiki/Newline>, in the
> form of a carriage return <http://en.wikipedia.org/wiki/Carriage_return>followed by a line
> feed <http://en.wikipedia.org/wiki/Line_feed>).
>
> *Server response*:
>
> HTTP/1.0 401 Unauthorized
> Server: HTTPd/0.9
> Date: Sun, 10 Apr 2005 20:26:47 GMT
> WWW-Authenticate: Digest realm="testrealm_at_host.com",
> qop="auth,auth-int",
> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
> opaque="5ccc069c403ebaf9f0171e9517f40e41"
> Content-Type: text/html
> Content-Length: 311
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
> <HTML>
> <HEAD>
> <TITLE>Error</TITLE>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
> </HEAD>
> <BODY><H1>401 Unauthorized.</H1></BODY>
> </HTML>
>
> *Client request (user name "Mufasa", password "Circle Of Life")*:
>
> GET /dir/index.html HTTP/1.0
> Host: localhost
> Authorization: Digest username="Mufasa",
> realm="testrealm_at_host.com",
> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
> uri="/dir/index.html",
> qop=auth,
> nc=00000001,
> cnonce="0a4f113b",
> response="6629fae49393a05397450978507c4ef1",
> opaque="5ccc069c403ebaf9f0171e9517f40e41"
>
> (followed by a blank line, as before).
>
> *Server response*:
>
> HTTP/1.0 200 OK
> Server: HTTPd/0.9
> Date: Sun, 10 Apr 2005 20:27:03 GMT
> Content-Type: text/html
> Content-Length: 7984
>
> (followed by a blank line and HTML text of the restricted page).
> ------------------------------
>
> The "response" value is calculated in three steps, as follows. Where values
> are combined, they are delimited <http://en.wikipedia.org/wiki/Delimiter>by
> colon <http://en.wikipedia.org/wiki/Colon_(punctuation)> symbols.
>
> 1. The MD5 hash of the combined user name, authentication realm and
> password is calculated. The result is referred to as HA1.
> 2. The MD5 hash of the combined method and digest URI<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier>is calculated, e.g. of
> "GET" and "/dir/index.html". The result is referred to as HA2.
> 3. The MD5 hash of the combined HA1 result, server nonce (nonce),
> request counter (nc), client nonce (cnonce), quality of protection code
> (qop) and HA2 result is calculated. The result is the "response" value
> provided by the client.
>
> Since the server has the same information as the client, the response can
> be checked by performing the same calculation. In the example given above
> the result is formed as follows – where MD5() represents a function used
> to calculate an MD5 hash, backslashes represent a continuation and the
> quotes shown are not used in the calculation.
>
> Completing the example given in RFC 2617<http://tools.ietf.org/html/rfc2617>gives the following results for each step.
>
> HA1 = MD5( "Mufasa:testrealm_at_host.com:Circle Of Life" )
> = 939e7578ed9e3c518a452acee763bce9
>
> HA2 = MD5( "GET:/dir/index.html" )
> = 39aff3a2bab6126f332b942af96d3366
>
> Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
> dcd98b7102dd2f0e8b11d0f600bfb0c093:\
> 00000001:0a4f113b:auth:\
> 39aff3a2bab6126f332b942af96d3366" )
> = 6629fae49393a05397450978507c4ef1
>
> At this point the client may make another request, reusing the server nonce
> value (the server only issues a new nonce for each "401" response) but
> providing a new client nonce (cnonce). For subsequent requests, the
> hexadecimal request counter (nc) must be greater than the last value it used
> – otherwise an attacker could simply "replay<http://en.wikipedia.org/wiki/Replay_attack>"
> an old request with the same credentials. It is up to the server to ensure
> that the counter increases for each of the nonce values that it has issued,
> rejecting any bad requests appropriately. Obviously changing the method, URI
> and/or counter value will result in a different response value.
>
> The server should remember nonce values that it has recently generated. It
> may also remember when each nonce value was issued, expiring them after a
> certain amount of time. If an expired value is used, the server should
> respond with the "401" status code and add stale=TRUE to the
> authentication header – indicating that the client should re-send with the
> new nonce provided, without prompting the user for another user name and
> password.
>
> The server does not need to keep any expired nonce values – it can simply
> assume that any unrecognised values have expired. It is also possible for
> the server to only allow each nonce value to be returned once, although this
> forces the client to repeat every request. Note that expiring a server nonce
> immediately will not work, as the client would never get a chance to use it.
>
> Thanks for you patience :)
>
> Sanjeeth
>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-05-18