Thanks Deepak!
Jacques
Le 09/11/2017 à 06:47, Deepak Dixit a écrit :
Done at r#1814704
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co
On Wed, Nov 8, 2017 at 10:15 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:
Thanks Jacques and Jacopo for details,
Sure
Done at r#1814704
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co
On Wed, Nov 8, 2017 at 10:15 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:
> Thanks Jacques and Jacopo for details,
>
> Sure Jacques, I'll do necessary changes.
>
> Thanks & Regards
> --
> Deepak
Thanks Jacques and Jacopo for details,
Sure Jacques, I'll do necessary changes.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co
On Tue, Nov 7, 2017 at 11:29 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Hi Jacopo,
>
> Thanks for the explanation about CryptoEx
Hi Jacopo,
Thanks for the explanation about CryptoException, this was really not obvious
to me, nice piece of code BTW.
Then I think we should revert my change and document about the CryptoException
to clarify in case another RuntimeException is crossed.
Will you handle it Deepak?
Jacques
Hi Jacques,
the pattern/best practice you are describing is definitely a valid one,
thanks for your explanations.
However, in this specific case, re-throwing the RuntimeException would not
work because when the field is encrypted with the old algorithm (3-DES),
the new Shiro code will fail to decr
Hi Deepak,
The problem as I see it is that if a RuntimeException is thrown by the 1st version of doDecrypt() then maybe the 2nd version of doDecrypt() will do
so. Maybe I'm wrong here, I did not check each method body.
Actually I think it's more a theoretical issue than a real one because amon
Hi Jacques,
I think we don't need to handle the RuntimeException, as doDecrypt fails to
decrypt then it will try with old pattern, I think this is for backward
compatibility.
Here is the comment from code
try using the old/bad hex encoding approach; this is another path the code
may take, ie if t
Hi Deepak,
Actually the rule is quite simple. If, for a reason, you decide to catch a
java.lang.Exception, you need to catch before the java.lang.RuntimeException.
This is because java.lang.RuntimeException is a java.lang.Exception so you
would hide possible runtime issues by only catching Exc
Thanks Jacques,
I was engage in other work so did not get a chance to test your
suggestion... :)
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co
On Fri, Nov 3, 2017 at 3:19 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Done at r1814155
>
> Jacques
>
> Le 01/11