Hi Florian, I may have missed the answer to my questions in your detailed problem description. But how is this not solved by URL-Encoding? There was once a bug with URL encodings in Camel. Does this bug still exist? What version of Camel are you using?
-Ralf ________________________________________ From: Florian Patzl <florian.pa...@evolit.com> Sent: Wednesday, June 3, 2020 2:49 PM To: users@camel.apache.org Subject: 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://stackoverflow.com/questions/11018987/camel-how-to-include-an-ampersand-as-data-in-a-uri-not-as-a-delimiter/34926623#34926623 Now, the solution in documentation is using the RAW(...) syntax: https://camel.apache.org/manual/latest/faq/how-do-i-configure-endpoints.html#HowdoIconfigureendpoints-Configuringparametervaluesusingrawvalues 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://issues.apache.org/jira/browse/CAMEL-12982 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=xxxxxx&2%7D&username=test2 The same problem existed for the RAW(...) syntax: https://issues.apache.org/jira/browse/CAMEL-11269 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://issues.apache.org/jira/browse/CAMEL-6230 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
