Thank you Keith for the valuable information.
Indeed, we have developed a Java API to manage the Broker via REST (Using Sprint Rest Template). However for now, we have been using unsecured channels for it. Regards, Adel ________________________________ From: Keith W <keith.w...@gmail.com> Sent: Thursday, March 30, 2017 10:22:28 AM To: users@qpid.apache.org Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency On 30 March 2017 at 08:49, Adel Boutros <adelbout...@live.com> wrote: > Thank you Rob, > > > Actually, we were wondering about the "dojo-1.10.3-distribution.zip" > available under the lib directory of the downloaded broker zip. So from your > answers, you only use it in the web console. > > Yes - this is correct. It is used only by the web management console. > One last question, what happens if we delete this dependency? Could we still > contact the broker via REST using SSL/SASL to manage queues, exchanges, etc? You'll see 404 errors if you attempt to use the Web Management Console but no harm is caused. The REST API, the Broker's ability to offer TLS (aka. SSL) and to offer SASL based authentication are all unaffected. Incidentally, if you are making programmatic use of the REST API, we recommend that you make use of preemptive authentication over a secure channel (that is. present an Authorization: header on your programatic HTTP request). The will give you a simpler application which makes fewer network interactions. You can do this from the command line using cURL (https://curl.haxx.se/docs/manpage.html#-u) > > > Regards, > > Adel > > ________________________________ > From: Rob Godfrey <rob.j.godf...@gmail.com> > Sent: Wednesday, March 29, 2017 11:38:30 PM > To: users@qpid.apache.org > Subject: Re: [Java Broker - 6.0.4] Dojo toolkit dependency > > Are you talking dojo itself, or the fact that the http-management plugin > also notes that it "This bundles portions of crypto-js, which is under the > MIT licence". > > The only "cryptographic functions" used within the web console are those > necessary to implement the necessary SASL authentication mechanisms. In > particular SHA-1, SHA-256 (and for historical reasons MD5) hashing. There > is no encryption used within the console (other than TLS through the > standard browser mechanism). The use of crypto-js code was because dojo > didn't have an implementation of the necessary HMAC mechanisms for SHA-1 / > SHA-256 if I remember correctly. (See https://tools.ietf.org/html/rfc5802 > and https://tools.ietf.org/html/rfc7677 for details of the SCRAM-SHA* SASL > mechanisms). > > Hope this helps, > Rob > > > > On 29 March 2017 at 21:17, Adel Boutros <adelbout...@live.com> wrote: > >> Hello, >> >> >> While our legal team was reviewing the Broker's packaged dependencies and >> their licenses, they had some questions regarding Dojo toolkit materials >> which I hope you can help me with: >> >> >> * Could you please list all cryptographic means contained in the dojo >> materials used? >> >> >> * Could you please describe: >> >> 1) the purpose(s) for which the dojo materials use these cryptographic >> means >> >> 2) whether these means will be accessible to end users >> >> >> * Why is this dependency needed and could we omit it from distribution? >> >> >> Regards, >> >> Adel >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
