Hi Florian,
I also had this problem. Neither URI encoding nor RAW helped. My solution in
2.x Camel was to use # notation in the URI with a String stored as
in a registry. Then Camel took the string and did not process it. It required
some fiddling with Registries to make them writable, but it was doable.
However, it seems that it does not work in Camel 3. Something like this is
"${ref:}, but when used with Strings, they are still somehow process by
Camel and in the end it fails with some special characters.
/Vojtech
From: Florian Patzl
Sent: Wednesday, June 3, 2020 14:49
To: users@camel.apache.org
Subject: [EXTERNAL] - Passwords in Camel endpoint URIs and limitations of RAW
syntax
Hello,
I'm trying to figure out the best way to handle passwords in Camel endpoint
URIs in my application.
I know the topic has been cause for Stack Overflow posts, JIRA entries and
mails but I'm still not sure I've got everything right.
Sorry for the big wall of text, but I think I should explain what exactly I've
tried and found out on the topic.
The main problem is that the reserved URI characters '+' and '&' (plus and
ampersand) cause parsing problems in Camel endpoint URIs.
'+' is replaced by a blank, and '&' is treated as the delimiter to the next
parameter.
An example URI for the password "pwd2+2":
pop3://localhost:3110/?username=test2&password=pwd2%2B2
A relevant post is here:
https://urldefense.com/v3/__https://stackoverflow.com/questions/11018987/camel-how-to-include-an-ampersand-as-data-in-a-uri-not-as-a-delimiter/34926623*34926623__;Iw!!Obbck6kTJA!KGASSfrNiG19hrz3XFpkjkI-DfK5STncbGLPofkcoybTnb0mkrK4hbqAKtilg8Ud$
Now, the solution in documentation is using the RAW(...) syntax:
https://urldefense.com/v3/__https://camel.apache.org/manual/latest/faq/how-do-i-configure-endpoints.html*HowdoIconfigureendpoints-Configuringparametervaluesusingrawvalues__;Iw!!Obbck6kTJA!KGASSfrNiG19hrz3XFpkjkI-DfK5STncbGLPofkcoybTnb0mkrK4hbqAKrPfyljz$
So for example:
pop3://localhost:3110/?username=test2&password=RAW(pwd2+2)
Using that feature means we can no longer treat Camel URIs as pure URIs in our
application, because the '+' of the password must not be escaped for this to
work.
But if there's no way around that, we can deal with that.
However, when trying the limits of the RAW(...) syntax, we noticed that it can
not parse passwords that contain ')&'.
This was covered in the following JIRA issue, and since then there is support
for an alternative syntax using curly braces: RAW{...}, that I didn't find in
documentation:
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/CAMEL-12982__;!!Obbck6kTJA!KGASSfrNiG19hrz3XFpkjkI-DfK5STncbGLPofkcoybTnb0mkrK4hbqAKkO9zER_$
The last comment provides a pretty detailed summary of the options and limits.
The alternative RAW{...} syntax works fine, except for a minor flaw: It breaks
URI sanitizing.
For example, Camel leaks the '&2' portion of the password 'pwd2&2' in log
entries like:
pop3://localhost:3110/?password=xx&2%7D&username=test2
The same problem existed for the RAW(...) syntax:
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/CAMEL-11269__;!!Obbck6kTJA!KGASSfrNiG19hrz3XFpkjkI-DfK5STncbGLPofkcoybTnb0mkrK4hbqAKinvp2KB$
So the fix should be rather simple, I will check whether there's already an
issue for that and might even be able to submit a PR for that.
But, more importantly: By checking the passwords for ')&' and '}&' and
dynamically deciding the RAW syntax to use, we should be able to support any
password *except* if they contain both ')&' and '}&'.
That is a weird constraint for passwords, but should be justifiable as
technical limitation.
As an alternative to all of this, I sometimes saw the suggestion to configure
the component with 'useRawUri':
* In DefaultComponent, useRawUri() is hardcoded to false. That means for
applying that to built-in components (e.g. Mail, FTP) we'd have to subclass the
components to override the method?
* Setting useRawUri on endpoint level does not seem to be supported:
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/CAMEL-6230__;!!Obbck6kTJA!KGASSfrNiG19hrz3XFpkjkI-DfK5STncbGLPofkcoybTnb0mkrK4hbqAKiki1NMf$
I tried that for the Mail component and got an error for unknown parameter
useRawUri.
So, is my conclusion correct that escaping passwords using RAW(...) or RAW{...}
- depending on the input - is the best approach for handling passwords in
endpoint URIs?
Or am I missing a different approach to configure the passwords on endpoints?
I've briefly read up on using property placeholders in URIs and saw that we'd
still have to use RAW(...) there. So I don't think that helps.
I _think_ completely moving away from endpoint URIs and instantiating endpoints
in plain Java code would also solve the issue, but that would require a couple
of major changes in our application.
Best regards,
Florian
