miner / clj-ftp

Clojure wrapper for Apache Commons Net for basic FTP

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Client URL user info is URL-decoded twice

samroberton opened this issue · comments

Legal URIs with URL-encoded usernames and/or passwords which include a '%' cause an exception in with-ftp because the user-info component is URL-decoded twice (once by urly, again by with-ftp).

The following fail with an exception:

  • (with-ftp [client "ftp://foo:password%25@localhost"] nil)
  • (with-ftp [client "ftp://foo:password%25a@localhost"] nil)

The following doesn't produce the exception, but attempts to authenticate with the wrong password:

  • (with-ftp [client "ftp://foo:password%25ab@localhost"] nil)

with-ftp first interprets the URL with urly/url-like, then calls (.getUserInfo) on the result, then decodes the username and password. However, urly's (.getUserInfo) already decodes the result, so it's being double-decoded.

There's actually another problem in here, too: the fact that urly decodes the user-info is a misfeature, in my opinion. It means that if either the username or password contain a :, it's impossible to tell whether it's supposed to be part of the username or password, because : is the delimiter.

The fix for #7 (ae56df7) had this correct, but the bug will have been introduced by the introduction of urly in dc3da76.

It seems like it's probably desirable to fix this by reverting back to using clojure.java.io/as-url to interpret the URL (and getting rid of urly), since that doesn't decode the user info component and doesn't introduce the problem with :. But it's possible there were other reasons for using urly that aren't obvious to me?

If you do want to keep urly, it might be worth documenting that this library won't work with usernames which contain a :. No doubt it's rare to have a username like that, but it is a legal URL.

Thanks for the detailed bug report and analysis. I'm going to out of town for a while so I won't be able to test and fix it for a while.

That's not a problem -- I expect I'll send you a PR early this week to save you the effort. Assuming I do, would you have any objections to removing urly and going back to clojure.java.io/as-url? Were there particular URL-like things that you wanted to be able to support that urly can handle and io/as-url can't?

If I remember correctly, urly was added by another contributor. It might have handled some encoding issues, but I'm not sure. I'll take the PR #22 and see if anyone complains.