URI encoding problems with passwords

[mattdrees]

Passwords with certain URI-reserved characters, like / and #, present challenges.

If you use / in the env map sent to SmbFileSystemProvider.newFilesystem(URI, Map), it is not percent-encoded before being concatenated into the URL that is fed into SmbFile, and you can get odd errors as a result.

For example, using username "foo" and password "bar/", you get

Exception in thread "main" java.net.MalformedURLException: For input string: "bar"
	at java.net.URL.<init>(URL.java:627)
	at jcifs.smb.SmbFile.<init>(SmbFile.java:485)
	at ch.pontius.nio.smb.SMBPath.getSmbFile(SMBPath.java:488)
	at ch.pontius.nio.smb.SMBFileSystemProvider.checkAccess(SMBFileSystemProvider.java:324)
	at org.cru.smb.Test.main(Test.java:29)
Caused by: java.lang.NumberFormatException: For input string: "bar"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:580)
	at java.lang.Integer.parseInt(Integer.java:615)
	at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:222)
	at jcifs.smb.Handler.parseURL(Handler.java:51)
	at java.net.URL.<init>(URL.java:622)
	... 4 more

To work around this, I would have to percent-encode the password in the env map.

A related problem is when I put the password into the URI (and not the env map) that I pass in to SmbFileSystemProvider.newFilesystem(URI, Map). In this case, I have to percent-encode the password so that I can construct a valid URI.

But SMBFileSystemProvider decodes this password, and does not re-encode it, when it sends it on to SmbFile.

So a uri like smb://foo:bar%[email protected]/some_share results in a stack trace like this:

Exception in thread "main" java.net.MalformedURLException: For input string: "bar"
	at java.net.URL.<init>(URL.java:627)
	at jcifs.smb.SmbFile.<init>(SmbFile.java:485)
	at ch.pontius.nio.smb.SMBPath.getSmbFile(SMBPath.java:488)
	at ch.pontius.nio.smb.SMBFileSystemProvider.checkAccess(SMBFileSystemProvider.java:324)
	at org.cru.smb.Test.main(Test.java:42)
Caused by: java.lang.NumberFormatException: For input string: "bar"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:580)
	at java.lang.Integer.parseInt(Integer.java:615)
	at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:222)
	at jcifs.smb.Handler.parseURL(Handler.java:51)
	at java.net.URL.<init>(URL.java:622)
	... 4 more

To work around this, I would have to double percent-encode the password in the URI.

[ppanopticon]

Thanks for reporting this issue! I just made a commit that should fix both issues.

Can you confirm that?

[mattdrees]

Thanks for taking a look.

I'll do some testing. But looking at your commit, I'm not sure using URLEncoder is the right thing to do; it's meant for application/x-www-form-urlencoded encoding, so it might not handle spaces correctly.

[ppanopticon]

Fair point. But do we expect spaces in usernames and password?

[mattdrees]

I dunno. Pretty unlikely for sure, but I don't know enough about SMB to know if it's actually illegal.

[mattdrees]

Ok, I tested.

You fixed the first problem, but not the second.
Here's a test that shows the problem:

    public static void main(String[] args) throws IOException
    {
        Map<String, ?> env = new HashMap<>();
        final SMBFileSystem fileSystem = new SMBFileSystemProvider().newFileSystem(
            URI.create("smb://foo:bar%[email protected]/exampleshare/"),
            env);
        final Path check = fileSystem.getPath("share", "check/");
        fileSystem.provider().checkAccess(check, READ);
        fileSystem.close();
    }