JDK-6234804 : REGRESSION: Digest Access Authentication (RFC 2617) not working - missing "
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0,6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows_2003
  • CPU: x86
  • Submitted: 2005-03-02
  • Updated: 2011-02-16
  • Resolved: 2005-03-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u4Fixed 6 betaFixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux Suse 9.1 (Linux kaos 2.4.21-99-athlon #1 Wed Sep 24 13:34:32 UTC 2003 i686 athlon i386 GNU/Linux)
Windows XP SP2

EXTRA RELEVANT SYSTEM CONFIGURATION :
etherreal, valid labs.zap2it acount, apache webserver (for at-home-testing)

A DESCRIPTION OF THE PROBLEM :
Tring to use RFC 2617-style login.

java 1.5.0_1 returns this (coded values changing form login to login):
Authorization: Digest username="pumpkin00", realm="TMSWebServiceRealm", nonce="PDExMDkyNzczNDIxOTYuYjBhYjQxMjIzNzkxMTk5ZjI1YmY5ZjU3NjdkOWMxZGNAb
mlnaHRmbGlnaHQ+", nc=00000001, uri="/tvlistings/xtvdService", response="25a26a5ef477644c87e8cf1e58320127", algorithm=MD5", opaque="c3601474d6290
e78, cnonce="OPNEANJLDPBCBBHGPFJBJMMBBOJBCEEOHALJLGAF", qop="auth"

The leading "-sign is missing in [ algorithm=MD5" ]. All tested servers reject login.


1.4.2 returns this:
Authorization: Digest username="pumpkin00", realm="TMSWebServiceRealm", nonce="PDExMDkyNzIyOTU4NzYuNjUzODhiYWI3YmJjOGRjODVkMzQwZTVlOWExOTRjNWZAb
mlnaHRmbGlnaHQ+", uri="/tvlistings/xtvdService", response="587ef477ae6db1c2916c631996864efd", algorithm="MD5", opaque="7680c3b98d5b515a", nc=00000001, cnonce="KLCLNPOCICBKEAELADBAHMLMOEOCPCBHOBLGHOND", qop="auth"

including all "-signs. All tested server accept this login.

See BugID: 4759514 for simelar problem in 1.4.1 (resolved 1.4.2)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Extend Authenticator-class. Make that class return a PasswordAuthentication-Object (including real Username/password) for a http-server. Set that Authenticator using:

Authenticator.setDefault(new myAuth());

Try to connect to http-server.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
succesful login (HTTP-respone 200)
ACTUAL -
using java1.5.0_1:
HTTP/1.1 401 Unauthorized

using java1.4.2 (same class-file)
HTTP/1.1 200


ERROR MESSAGES/STACK TRACES THAT OCCUR :
No relevant java-side crashs, errors or exceptions


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.net.*;
import java.io.*;

class myAuth extends Authenticator {

   protected PasswordAuthentication getPasswordAuthentication() {
      return new PasswordAuthentication("YOUR-USERNAME-HERE", "YOUR-PASSWORD-HERE".toCharArray());
   }

}

public class MyURL {

   public static void main(String[] args) throws Exception {

      Authenticator.setDefault(new myAuth());

      // one of the tested servers:
      URL url = new URL("http://datadirect.webservices.zap2it.com/tvlistings/xtvdService");

      HttpURLConnection URLC = (HttpURLConnection) url.openConnection();

      //this part only makes the server react. It is NOT related to the bug.
      //This server only asks for login then providing a valid SOAP-message.
      URLC.setRequestProperty( "Accept-Encoding", "gzip" );
      URLC.setRequestProperty( "SOAPAction", "urn:TMSWebServices:xtvdWebService#download" );
      URLC.setRequestMethod( "POST" );
      URLC.setDoInput( true );
      URLC.setDoOutput( true );
      URLC.setUseCaches( false );
      String request =
      "<?xml version='1.0' encoding='UTF-8'?>"+
      "<SOAP-ENV:Envelope SOAP-ENV:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'\n"+
      "xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/'\n"+
      "xmlns:xsd='http://www.w3.org/2001/XMLSchema'\n"+
      "xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'\n"+
      "xmlns:SOAP-ENC='http://schemas.xmlsoap.org/soap/encoding/'>\n"+
      "<SOAP-ENV:Body>\n"+
      "<tms:download xmlns:tms='urn:TMSWebServices'>\n"+
      "<startTime xsi:type='tms:dateTime'>2005-02-23T08:39:11Z</startTime>\n"+
      "<endTime xsi:type='tms:dateTime'>2005-02-24T08:39:11Z</endTime>\n"+
      "</tms:download>\n"+
      "</SOAP-ENV:Body>\n"+
      "</SOAP-ENV:Envelope>";


      //Bug hits here, while trying login:

      PrintWriter writer = new PrintWriter( URLC.getOutputStream() );
      writer.println( request );
      writer.flush();
      writer.close();
      
      System.out.println (URLC.getResponseCode());
      System.out.println (URLC.getResponseMessage());
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Using 1.4.2 (or another RFC2617-implementation)

Release Regression From : 5.0
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
###@###.### 2005-03-02 09:11:00 GMT

Comments
EVALUATION Re-produced; see mismatched quotation mark in http request when 401 response has the opaque attribute setted. Will fix in mustang and a 5.0 update release. ###@###.### 2005-03-03 03:42:03 GMT
03-03-2005