https://issues.apache.org/jira/browse/TOMEE-1603


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-06-11 3:37 GMT+02:00 Romain Manni-Bucau <[email protected]>:

> Yeah like a class you instantiate yourself or not cdi managed (like jpa
> entities). Scanned but not managed.
>  Le 10 juin 2015 05:05, "Alex Soto" <[email protected]> a écrit :
>
>> Hi I would like to share this experience with CDI and PasswordCipher:
>>
>> If I do next code:
>>
>> public class SecurePasswordCipher implements PasswordCipher {
>>
>>     @Inject
>>
>>     MasterPasswordProvider masterPasswordProvider;
>> }
>>
>> And no MasterPasswordProvider implementation is provided, I get next
>> exception:
>>
>> Caused by: javax.enterprise.inject.UnsatisfiedResolutionException: Api
>> type
>> [com.scytl.multitenant.MasterPasswordProvider] is not found with the
>> qualifiers
>>
>> Qualifiers: [@javax.enterprise.inject.Default()]
>>
>> for injection into Field Injection Point, field name :
>> masterPasswordProvider, Bean Owner : [SecurePasswordCipher, Name:null,
>> WebBeans Type:MANAGED, API
>>
>> Types:[com.scytl.multitenant.SecurePasswordCipher,java.lang.Object,org.apache.openejb.cipher.PasswordCipher],
>> Qualifiers:[javax.enterprise.inject.Default,javax.enterprise.inject.Any]]
>>
>>
>> But I create an implementation:
>>
>> Then this exception is not thrown, in fact it works all, but the injection
>> is null. I don't know if this helps you or not.
>>
>>
>> Alex.
>>
>>
>> El dc., 10 juny 2015 a les 10:35, Romain Manni-Bucau (<
>> [email protected]>)
>> va escriure:
>>
>> > That's a good point!
>> >
>> > Pre-side note/history: on a pure PasswordCipher aspect it was not an
>> issue
>> > until recently (j8 something) cause constant pool was not used/usable
>> for
>> > all strings.
>> >
>> > On a pure technical aspect and our API: most of modern API use a String
>> >  (datasources, JavaEE API like HttpServletRequest...or JavaSE with
>> > DriverManager) so we can't really help in our own API (ie we can fix it
>> but
>> > then you get the same issue elswhere).
>> >
>> > So yes there is potentially an issue but if you think more to which
>> kind of
>> > attack you can get I would worry about a lot of other things before
>> > worrying about password since it requires already advanced accesses to
>> the
>> > box.
>> >
>> >
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> > <http://www.tomitribe.com>
>> >
>> > 2015-06-10 10:17 GMT+02:00 Alex Soto <[email protected]>:
>> >
>> > > One thing about PasswordCipher, because you are planning to rework :)
>> My
>> > > security team (which sometimes are a bit crazy) noticed me that this
>> > > interface deals with passwords as Strings. This can be a security
>> problem
>> > > since Strings are immutable and not destroyed (they are pooled), so it
>> > can
>> > > be a security problem since instances are always live.
>> > > In fact in my company we always treat passwords as byte[].
>> > >
>> > > We even transform char[] using this algorithm:
>> > >
>> > > ByteBuffer bb = CHARSET.encode(CharBuffer.wrap(password));
>> > > byte[] asBytes = new byte[bb.remaining()];
>> > > bb.get(asBytes);
>> > >
>> > > So paranoic level is high I know, but at the end it is about security.
>> > >
>> > > WDYT?
>> > >
>> > > El dc., 10 juny 2015 a les 10:01, Romain Manni-Bucau (<
>> > > [email protected]>)
>> > > va escriure:
>> > >
>> > > > yeah, fully agree.
>> > > >
>> > > > The few points which make PasswordCipher different are:
>> > > > - they are "prototype" (short live instances)
>> > > > - they are not bound to any application by default (so no cdi)
>> > > >
>> > > > That said it shouldnt be hard to get a PasswordCipher which is
>> > actually a
>> > > > cdi bridge one (ie we dont add cdi by default but allow to ask for
>> it):
>> > > > cipher:cdi:org.supercompany.SuperPwdCipher:encoded. The bridge
>> would:
>> > > > 1) ensure there is a "current" cdi context
>> > > > 2) create the instance
>> > > > 3) decode as expected
>> > > > 4) release the creation context is the instance was not normal
>> scoped
>> > > >
>> > > > In term of impl it can just be a plain olf proxy delegating to an
>> > > > invocation handler with this logic.
>> > > >
>> > > > wdyt? Do you want to have a try? Any other idea we could use?
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > > > <http://rmannibucau.wordpress.com> | Github <
>> > > > https://github.com/rmannibucau> |
>> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> > > > <http://www.tomitribe.com>
>> > > >
>> > > > 2015-06-10 9:48 GMT+02:00 Jonathan Gallimore <
>> [email protected]
>> > >:
>> > > >
>> > > > > Go for it :) - not sure what's involved off the top of my head,
>> but
>> > am
>> > > > > happy to help dig into the code.
>> > > > >
>> > > > > Jon
>> > > > >
>> > > > > On Wed, Jun 10, 2015 at 7:42 AM, Alex Soto <[email protected]>
>> > wrote:
>> > > > >
>> > > > > > Ok no problem at all because I will implement the logic I need
>> as a
>> > > JDK
>> > > > > > service, but I think that will be great to have all classes that
>> > can
>> > > be
>> > > > > > extended in TomEE by a developer to be CDI aware like
>> > AbstractRouter.
>> > > > > >
>> > > > > > If you want I can send this on devel mailing list.
>> > > > > >
>> > > > > > Alex
>> > > > > >
>> > > > > > El dt., 9 juny 2015 a les 21:41, Jean-Louis Monteiro (<
>> > > > > > [email protected]>) va escriure:
>> > > > > >
>> > > > > > > No supported at the minute
>> > > > > > >
>> > > > > > > --
>> > > > > > > Jean-Louis Monteiro
>> > > > > > > http://twitter.com/jlouismonteiro
>> > > > > > > http://www.tomitribe.com
>> > > > > > >
>> > > > > > > On Tue, Jun 9, 2015 at 4:41 PM, Romain Manni-Bucau <
>> > > > > > [email protected]>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > think it is not supported
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Romain Manni-Bucau
>> > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > > > > > > > <http://rmannibucau.wordpress.com> | Github <
>> > > > > > > > https://github.com/rmannibucau> |
>> > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
>> > Tomitriber
>> > > > > > > > <http://www.tomitribe.com>
>> > > > > > > >
>> > > > > > > > 2015-06-09 16:39 GMT+02:00 Alex Soto <[email protected]>:
>> > > > > > > >
>> > > > > > > > > Hi guys, can I use CDI annotations in implementations of
>> > > > > > > > >
>> > > > > > > > > org.apache.openejb.cipher.PasswordCipher using OpenEJB
>> > 4.7.2? I
>> > > > > have
>> > > > > > > > tried
>> > > > > > > > > but no injection occurs, and to know if it is because I am
>> > > doing
>> > > > > > > > something
>> > > > > > > > > wrong or simply it is not supported.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > Alex.
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Jonathan Gallimore
>> > > > > http://twitter.com/jongallimore
>> > > > > http://www.tomitribe.com
>> > > > >
>> > > >
>> > >
>> >
>>
>

Reply via email to