Re: RFR 7150092: NTLM authentication fail if user specified a different realm
Ping again. On Jun 12, 2014, at 14:07, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/7150092/webrev.00/ > > The problem is that in NTLM, the server might prompt for a domain name (in > Type 2 message), and the client can also provide one. Before this fix, if the > two are different, the client chooses the one from the server. After this > fix, the client will always uses its own even if it's empty. This is > confirmed by looking at the behavior of IE/Firefox/Chrome. The server sent > domain name was designed to be used to create the NTLMv2 response but it's > now obsoleted by alist. Chrome/Firefox simply ignore it, so will Java. (IE > does use it if there is no alist) > > There are some other small changes: > > Client.java > --- > > 96-108: No one sends hostname and domain in the Type 1 message, so they are > removed. Everyone adds a 0x4 flag which means Request Target. > > Removed old 137-139: That's the major change. > > 159: I used to detect whether there is an alist by looking at the length. > This is not accurate if the domain is very long. The correct way is to look > at the flag (0x80 means alist is there) > > Server.java > --- > > 98: Adds a flag 0x1 which means the target name (line 99) written into > the message is a domain > > 135: Always uses the client provided domain to search for password. This is > also a part of the major change. > > NTLMClient.java > --- > > If user has not responded to NameCallback and/or RealmCallback, it means they > accept the default value. > > NTLMServer.java > --- > > ntdomain could be empty or null, the 2-arg constructor of RealmCallback could > fail in this case. Use 1-arg constructor. > > NTLMAuthentication.java > --- > > According to my observation of IE/Firefox/Chrome, when user does not type in > a domain name in the password prompting dialog, the domain sent to server is > an empty string, and the host name is always full name. Update Java to be the > same. > > NTLMTest.java > - > > Update the test to reflect code changes. > > Thanks > Max >
RFR [9] 8047674: java/net/URLPermission/nstest/lookup.sh NoClassDefFoundError when run in concurrent mode
This test has been seen to fail occasionally when run with concurrency
enabled. I believe the reason to be two fold:
1) The order of the tags may trigger the compilation of the test
classes before the library classes, causing the test classes to
implicitly compile the library classes into the tests classes
directory, rather than the shared higher level library directory,
( if the library classes are not already compiled, hence the reason
the failure appears intermittently).
2) The test needs to specify the TESTCLASSPATH variable, rather than
TESTCLASSES. So it can find the library classes in the
shared higher level library directory.
diff --git a/test/java/net/URLPermission/nstest/lookup.sh
b/test/java/net/URLPermission/nstest/lookup.sh
--- a/test/java/net/URLPermission/nstest/lookup.sh
+++ b/test/java/net/URLPermission/nstest/lookup.sh
@@ -24,9 +24,9 @@
# @test
# @library /lib/testlibrary
+# @build jdk.testlibrary.*
# @compile -XDignore.symbol.file=true SimpleNameService.java
#LookupTest.java SimpleNameServiceDescriptor.java
-# @build jdk.testlibrary.*
# @run shell/timeout=50 lookup.sh
#
@@ -42,8 +42,7 @@
;;
esac
-
-port=`${TESTJAVA}/bin/java -cp ${TESTCLASSES} LookupTest -getport`
+port=`${TESTJAVA}/bin/java -cp ${TESTCLASSPATH} LookupTest -getport`
cat << POLICY > policy
grant {
@@ -60,4 +59,4 @@
${TESTJAVA}/bin/java ${TESTVMOPTS} \
-Djava.security.policy=file:./policy \
-Dsun.net.spi.nameservice.provider.1=simple,sun \
--cp ${TESTCLASSES}${PS}${TESTSRC} LookupTest -runtest ${port}
+-cp ${TESTCLASSPATH}${PS}${TESTSRC} LookupTest -runtest ${port}
-Chris.
Re: RFR [9] 8047674: java/net/URLPermission/nstest/lookup.sh NoClassDefFoundError when run in concurrent mode
On 23/06/2014 11:51, Chris Hegarty wrote: This test has been seen to fail occasionally when run with concurrency enabled. I believe the reason to be two fold: I don't know if the order matter here because the @build should compile all of jdk.testlibrary.*. However, I think it's worth trying and so the changes look good to me. -Alan.
Re: RFR [9] 8047674: java/net/URLPermission/nstest/lookup.sh NoClassDefFoundError when run in concurrent mode
On 23/06/14 11:55, Alan Bateman wrote: On 23/06/2014 11:51, Chris Hegarty wrote: This test has been seen to fail occasionally when run with concurrency enabled. I believe the reason to be two fold: I don't know if the order matter here because the @build should compile all of jdk.testlibrary.*. However, I think it's worth trying and so the changes look good to me. Yes, it does compile all of jdk.testlibrary.*, but the order determines where the classes end up. If the testlibrary classes are compiled implicitly during the compilation of the test classes, then the testlibrary classes end up in TESTCLASSES. And the test succeeds. If the testlibrary is already compiled (by another test), then the @build does nothing, and the test classes are compiled into TESTCLASSES. The test invokes the java launcher directly passing TESTCLASSES to -cp. This fails because TESTCLASSES does not contain the testlibrary classes. With the second part of the suggested change, replace TESTCLASSES with TESTCLASSPATH, the order of the tags does not have any impact on whether the test passes or fails. But without fixing the order you can end up needlessly compiling the testlibrary classes into TESTCLASSES. -Chris. -Alan.
