Hi Florian, As Fabry mentioned, it would be worth checking to use config file to achieve this. Here is an example: https://github.com/apache/camel-examples/tree/master/examples/camel-example-debezium
Regards, Omar On Thu, Jun 4, 2020 at 10:56 AM FabryProg <fabryp...@gmail.com> wrote: > Hello Florian, > > Did you try to save the password into a variable / parameter / config file > and lookup it into the URI? > > Kind regards! > > Il giorno gio 4 giu 2020 alle ore 10:50 Florian Patzl < > florian.pa...@evolit.com> ha scritto: > > > Hello Ralf, > > thanks for your response. No, I didn't mention that in my description. > :-) > > URL encoding would be my preferred solution, too, but unfortunately that > > does not seem to prevent the problems with passwords containing ")&". > > Unless something about my encoding is wrong. > > > > For example, given a password "pwd)&a=b", both with and without RAW(...) > > the result is wrong: > > > > TRACE o.a.c.i.engine.AbstractCamelContext - Getting endpoint with raw > uri: > > pop3://localhost:3110/?username=test2&password=RAW%28pwd%29%26a%3Db%29, > > normalized uri: > > pop3://localhost:3110/?a=b%29&password=RAW(pwd)&username=test2 > > > > TRACE o.a.c.i.engine.AbstractCamelContext - Getting endpoint with raw > uri: > > pop3://localhost:3110/?username=test2&password=pwd%29%26a%3Db, normalized > > uri: pop3://localhost:3110/?a=b&password=pwd%29&username=test2 > > > > I'm currently testing on 3.3.0. > > > > Best Regards, > > Florian > > ________________________________ > > From: Claussnitzer, Ralf <ralf.claussnit...@slub-dresden.de> > > Sent: Thursday, June 4, 2020 08:13 > > To: users@camel.apache.org <users@camel.apache.org> > > Subject: Re: Passwords in Camel endpoint URIs and limitations of RAW > syntax > > > > 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 > > >
