[jcifs] there is a mistake in jcifs-1.2.9.jar about SmbFile constructor

Eric Glass eric.glass at gmail.com
Wed Dec 13 11:55:02 GMT 2006


> The bottom line is:
>
> 1) SmbFile passes URLs directly to java.net.URL. So whatever the case is,
> it's a problem with java.net.URL. You can see the exceptions are being
> thrown from within java.net.URL. We could probably work around it but ...
>

The problem is that our jcifs.smb.Handler class (which interprets the
raw URL string on behalf of java.net.URL) unescapes the userinfo
during parsing, which is inconsistent with "normal" URLStreamHandler
implementations:


import java.net.*;

public class testurl {

    public static void main(String[] args) throws Exception {
        URL url = new URL("http://test:test%25n1234@example.com/");
        System.out.println(url.getUserInfo()); // prints "test:test%25n1234"
        System.setProperty("java.protocol.handler.pkgs", "jcifs");
        url = new URL("smb://test:test%25n1234@example.com/");
        System.out.println(url.getUserInfo()); // prints "test:test%n1234"
    }

}


The issue arises when the SmbFile(SmbFile, String) constructor is
called and the base SmbFile was created as above; the underlying base
URL now holds the userinfo in an unescaped representation (i.e.
"test%n1234"), and creating a relative SMB URL tries to unescape it a
second time.

The solution is to move the unescape code from the Handler class into
the NtlmPasswordAuthentication(String) constructor (patch attached).
I don't think this would have any impact outside of this constructor
(which is only there to support the Handler anyway) but your mileage
may vary...


Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urlfix.patch
Type: application/octet-stream
Size: 4689 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20061213/b13d0b34/urlfix.obj


More information about the jcifs mailing list