Hi Ray, This is really awesome!! Thierry and I were a bit worried about this feature planned for version 1.1 : now the sun shines again :)
I've added your patch and initial message to the related issue: http://restlet.tigris.org/issues/show_bug.cgi?id=64 Let's continue the discussion via issue comment system... Best regards, Jerome > -----Message d'origine----- > De : Ray Waldin [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 19 avril 2007 19:44 > À : [email protected] > Objet : HTTP Digest Authentication > > Hi all, > > Attached is an implementation of HTTP Digest Authentication > (both client and server) for the RESTlet 1.0.0 framework. > Included are six files: > > 1) Patch to ChallengeResponse which adds a field to store the > many components of a digest authentication credentials statement. > > 2) Patch to SecurityUtils which: > a) adds digest auth handling to both format() methods and > also to parseResponse() and parseRequest() > b) adds a number of support methods, like makeNonce(), and md5String() > > 3 & 4) the above files, patched > > 5) new HttpDigestGuard class that extends Guard with support > for server side digest authentication. > > 6) new HttpDigestClient class that extends Client with > support for client side digest authentication. > > The client side support is lacking in many ways, particularly > in it's inability to preemptively authenticate on subsequent > requests. I'm not sure if reimplementing client-side > authentication is the right way to go, since it already > exists in the underlying HttpClient and URLConnection libs. > Probably connecting to those implementations makes more > sense, but I needed something fast... The cient side support > has only been tested against HttpDigestGuard. > > The server side support is pretty solid, and has been tested > against the included HttpDigestClient, Safari (2.0.4), > Firefox (2.0.0.3), and IE 6. Only qop=auth and algorithm=MD5 > are supported. > > Installing the guard is pretty straightforward: > > > Guard g = new HttpDigestGuard(getContext(), > "someRealm", Collections.singleton("/someBasePath/"), > "someServerKey") { > // let anyone login with password "password"! > protected char[] findSecret(String identifier) {return > "password".toCharArray();} > }; > g.setNext(myRestlet); > > > as is using the client: > > > Client client = new HttpDigestClient(getContext(), > "someClientKey") { > // trylogging in as username/password > "admin"/"password" for all resource references > public String getUsername(Reference ref) {return "admin";} > public char[] getPassword(Reference ref) {return > "password".toCharArray();} > }; > Response response = client.get(someReference); > > > > Both classes are abstract and require you to implement > callbacks to retrieve username and/or passwords. Due to the > nature of digest authentication, use of checkSecret() is not > possible -- there is no password sent from the client to > check. Also, due to the nature of digest authentication, the > server may chose to store password digests instead of > passwords. To do this, override the > HttpDigestGuard.getHashedSecret() method instead of > findSecret(), and store and return the string specified as A1 > in section 3.2.2.2 of RFC2617, that is: md5string(username > ":" realm ":" password) > > Enjoy! > > -Ray > >
