RAW(…) function work for
recipientList EIP? We have currently an issue with an S/FTP server we have to connect to to which we have been assigned a password that contains a couple of special characters.
According to RFC 3986 the user information part of the URI defines the rule-set which characters need to be percent-encoded and which don’t. We utilize Springs UriUtils class to encode the password according to the RFC 3986 ruleset and generate the Camel endpoint configuration string based on that result. This URI is furthermore altered by adding the above-mentioned
RAW(…) function to it to tell Camel to not encode the already encoded user information.
In a test we end up with a Camel endpoint configuration string similar to
String connectionString = „ftp://RAW(user:se+re$%3Ft&23)@127.0.0.1:1101/?throwExceptionOnConnectFailed=true&stepwise=false“
for a raw password of
se+re$?t&23 though when we feed the
recipientList EIP with such a configuration string the actual server is invoked, however the credentials within the authentication routine are as such:
username = "RAW(user" password = "se+re$?t&23)"
where the password seems to correctly be decoded by that server though the leading
RAW(and the trailing
) characters from the
RAW(…) function are not removed for some reason before sending the request.
If we omit the
RAW(…) function and use the raw URI (
ftp://user:se+re$%3Ftfirstname.lastname@example.org:1101/?throwExceptionOnConnectFailed=true&stepwise=false), Camel can’t even invoke the server and fails with the following reason:
Caused by: java.lang.IllegalArgumentException: host must be specified and not empty at org.apache.camel.util.StringHelper.notEmpty(StringHelper.java:323) at org.apache.camel.util.ObjectHelper.notEmpty(ObjectHelper.java:357) at org.apache.camel.component.file.remote.RemoteFileEndpoint.afterPropertiesSet(RemoteFileEndpoint.java:154) at org.apache.camel.component.file.remote.RemoteFileEndpoint.createProducer(RemoteFileEndpoint.java:88) at org.apache.camel.component.file.remote.RemoteFileEndpoint.createProducer(RemoteFileEndpoint.java:36)
Tend enter what I’m more or less looking for, such as
recipientListor the like. Finding the same „page“ in the current layout is not that user-friendly IMO. Not sure though if there is already a JIIRA ticket available for that
OK, I think I understand where the issue is at. There are actually 2 issues IMO. One of them being that when the
FtpComponent receives the
String uri within
buildFileEndpoint(…) it still has the
RAW(…) stuff included. This
RAW(…) function is used within
UnsafeUriCharactersEncoder to not encode characters defined within that function. This is mentioned in the docs, though I’d expected that this will remove the
) parts in the actual target URI also. This issue could be fixed by customizing the
FtpComponent and remove that parts from the uri-string manually.
The other one seems to be related with how URIs are generated and encoded internally. What I find strange is, that Camel generates a
URI object in
URISupport.normalizeUri(String uri) by encoding it using an obsolete URL spec (RFC 1738) intead of the actual current URI spec RFC 3986, which obviously defines other reserved and admissible characters. This way, not adding
RAW(…) at all will strip away the host information for an already encoded password such as
se+re$%3Ft&23 and also decode that encoded password back to
se+re$?t23 which is not in line with the actual URI spec IMO.
RAW(…)function is used within a FTP component configuration string using a
passwordproperty, i.e. something along the line of
ftp://user@host:port/path/to/dir?stepwise=false&password=RAW(se+re$?t23)&...everything seems to work as expected. As the password included in the user info section of the URI is deprecated anyway this is probably the clean and correct way to specify passwords to start with.