You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Alex Soto <as...@gmail.com> on 2015/09/19 09:33:00 UTC
CDI proxy and instance of
Hello, I am developing a very simple Java EE application that generates a
JWT token. Currently I am using JJWT library to generate it. To generate a
token I need the claims and a key. For generating the key I am using next
code:
public class SecretKeyProducer {
@Produces
@ApplicationScoped
public Key generateJwtSignKey() {
return MacProvider.generateKey();
}
}
Then I inject the key in the service responsible to create the token:
@Inject
Key keyForSigning;
public String generateToken(String login) {
System.out.println(keyForSigning);
final String token =
Jwts.builder().setSubject(login).signWith(SignatureAlgorithm.HS256,
keyForSigning).compact();
return token;
}
The problem is that next exception is thrown:
java.lang.IllegalArgumentException: MAC signatures must be computed and
verified using a SecretKey. The specified key of type
org.apache.webbeans.custom.security.Key$$OwbNormalScopeProxy0 is not a
SecretKey.
The problem is that JJWT do an instanceof:
public MacSigner(SignatureAlgorithm alg, Key key) {
super(alg, key);
Assert.isTrue(alg.isHmac(), "The MacSigner only supports HMAC
signature algorithms.");
if (!(key instanceof SecretKey)) {
String msg = "MAC signatures must be computed and verified
using a SecretKey. The specified key of " +
"type " + key.getClass().getName() + " is not a
SecretKey.";
throw new IllegalArgumentException(msg);
}
}
So is there a way from CDI point of view to fix this?
Thank you very much.
Re: CDI proxy and instance of
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Produce kt without scope - ie dependent - and ensure it is app scope using
an app scope bean holding it - ie the wrapping bean is app scope, stores
the key in posconstruct and return always the same instance.
Le 19 sept. 2015 07:48, "Alex Soto" <as...@gmail.com> a écrit :
> Thanks Andy, well my idea was to add some CDIsh in jwt. I thought about
> wrapping too but I would prefer a more native approach :D but well I am
> going to try Uday approach and if not works to wrap
>
> Thank you so much
>
> El ds, 19 set 2015 a les 12:22 Andy Gumbrecht
> agumbrecht@tomitribe.com> va escriure:
>
> That should work, but what is the use case for injection? To have the
> > option to swap out MacProvider.generateKey() with a different impl later?
> >
> > Another option would be to wrap the generated key payload (algorithm,
> > bytes) in your own produced object and create a new SecretKeySpec(bytes,
> > algname); in generateToken.
> >
> > Andy.
> >
> > On 19/09/2015 10:16, Uday Gire wrote:
> > > Hi Alex
> > >
> > > Try to produce SecretKEy not Key
> > >
> > > @Produces
> > > @ApplicationScoped
> > > public SecretKEy generate(){
> > > }
> > >
> > > @Inject
> > > SecretKey keyforsigning;
> > >
> > > Best
> > >
> > > Uday
> > > ManageCat, http://www.managecat.com <http://www.managecat.com/>
> > >
> > >> On 19 Sep 2015, at 10:33, Alex Soto <as...@gmail.com> wrote:
> > >>
> > >> Hello, I am developing a very simple Java EE application that
> generates
> > a
> > >> JWT token. Currently I am using JJWT library to generate it. To
> > generate a
> > >> token I need the claims and a key. For generating the key I am using
> > next
> > >> code:
> > >>
> > >> public class SecretKeyProducer {
> > >>
> > >> @Produces
> > >> @ApplicationScoped
> > >> public Key generateJwtSignKey() {
> > >> return MacProvider.generateKey();
> > >> }
> > >>
> > >> }
> > >>
> > >>
> > >> Then I inject the key in the service responsible to create the token:
> > >>
> > >> @Inject
> > >> Key keyForSigning;
> > >>
> > >> public String generateToken(String login) {
> > >> System.out.println(keyForSigning);
> > >> final String token =
> > >> Jwts.builder().setSubject(login).signWith(SignatureAlgorithm.HS256,
> > >> keyForSigning).compact();
> > >> return token;
> > >> }
> > >>
> > >>
> > >> The problem is that next exception is thrown:
> > >>
> > >> java.lang.IllegalArgumentException: MAC signatures must be computed
> and
> > >> verified using a SecretKey. The specified key of type
> > >> org.apache.webbeans.custom.security.Key$$OwbNormalScopeProxy0 is not a
> > >> SecretKey.
> > >>
> > >> The problem is that JJWT do an instanceof:
> > >>
> > >> public MacSigner(SignatureAlgorithm alg, Key key) {
> > >> super(alg, key);
> > >> Assert.isTrue(alg.isHmac(), "The MacSigner only supports HMAC
> > >> signature algorithms.");
> > >> if (!(key instanceof SecretKey)) {
> > >> String msg = "MAC signatures must be computed and verified
> > >> using a SecretKey. The specified key of " +
> > >> "type " + key.getClass().getName() + " is not a
> > >> SecretKey.";
> > >> throw new IllegalArgumentException(msg);
> > >> }
> > >> }
> > >>
> > >>
> > >> So is there a way from CDI point of view to fix this?
> > >>
> > >> Thank you very much.
> > >
> > >
> > >
> >
> > --
> > Andy Gumbrecht
> > https://twitter.com/AndyGeeDe
> > http://www.tomitribe.com
> >
> >
>
Re: CDI proxy and instance of
Posted by Alex Soto <as...@gmail.com>.
Thanks Andy, well my idea was to add some CDIsh in jwt. I thought about
wrapping too but I would prefer a more native approach :D but well I am
going to try Uday approach and if not works to wrap
Thank you so much
El ds, 19 set 2015 a les 12:22 Andy Gumbrecht
agumbrecht@tomitribe.com> va escriure:
That should work, but what is the use case for injection? To have the
> option to swap out MacProvider.generateKey() with a different impl later?
>
> Another option would be to wrap the generated key payload (algorithm,
> bytes) in your own produced object and create a new SecretKeySpec(bytes,
> algname); in generateToken.
>
> Andy.
>
> On 19/09/2015 10:16, Uday Gire wrote:
> > Hi Alex
> >
> > Try to produce SecretKEy not Key
> >
> > @Produces
> > @ApplicationScoped
> > public SecretKEy generate(){
> > }
> >
> > @Inject
> > SecretKey keyforsigning;
> >
> > Best
> >
> > Uday
> > ManageCat, http://www.managecat.com <http://www.managecat.com/>
> >
> >> On 19 Sep 2015, at 10:33, Alex Soto <as...@gmail.com> wrote:
> >>
> >> Hello, I am developing a very simple Java EE application that generates
> a
> >> JWT token. Currently I am using JJWT library to generate it. To
> generate a
> >> token I need the claims and a key. For generating the key I am using
> next
> >> code:
> >>
> >> public class SecretKeyProducer {
> >>
> >> @Produces
> >> @ApplicationScoped
> >> public Key generateJwtSignKey() {
> >> return MacProvider.generateKey();
> >> }
> >>
> >> }
> >>
> >>
> >> Then I inject the key in the service responsible to create the token:
> >>
> >> @Inject
> >> Key keyForSigning;
> >>
> >> public String generateToken(String login) {
> >> System.out.println(keyForSigning);
> >> final String token =
> >> Jwts.builder().setSubject(login).signWith(SignatureAlgorithm.HS256,
> >> keyForSigning).compact();
> >> return token;
> >> }
> >>
> >>
> >> The problem is that next exception is thrown:
> >>
> >> java.lang.IllegalArgumentException: MAC signatures must be computed and
> >> verified using a SecretKey. The specified key of type
> >> org.apache.webbeans.custom.security.Key$$OwbNormalScopeProxy0 is not a
> >> SecretKey.
> >>
> >> The problem is that JJWT do an instanceof:
> >>
> >> public MacSigner(SignatureAlgorithm alg, Key key) {
> >> super(alg, key);
> >> Assert.isTrue(alg.isHmac(), "The MacSigner only supports HMAC
> >> signature algorithms.");
> >> if (!(key instanceof SecretKey)) {
> >> String msg = "MAC signatures must be computed and verified
> >> using a SecretKey. The specified key of " +
> >> "type " + key.getClass().getName() + " is not a
> >> SecretKey.";
> >> throw new IllegalArgumentException(msg);
> >> }
> >> }
> >>
> >>
> >> So is there a way from CDI point of view to fix this?
> >>
> >> Thank you very much.
> >
> >
> >
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
>
Re: CDI proxy and instance of
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
That should work, but what is the use case for injection? To have the
option to swap out MacProvider.generateKey() with a different impl later?
Another option would be to wrap the generated key payload (algorithm,
bytes) in your own produced object and create a new SecretKeySpec(bytes,
algname); in generateToken.
Andy.
On 19/09/2015 10:16, Uday Gire wrote:
> Hi Alex
>
> Try to produce SecretKEy not Key
>
> @Produces
> @ApplicationScoped
> public SecretKEy generate(){
> }
>
> @Inject
> SecretKey keyforsigning;
>
> Best
>
> Uday
> ManageCat, http://www.managecat.com <http://www.managecat.com/>
>
>> On 19 Sep 2015, at 10:33, Alex Soto <as...@gmail.com> wrote:
>>
>> Hello, I am developing a very simple Java EE application that generates a
>> JWT token. Currently I am using JJWT library to generate it. To generate a
>> token I need the claims and a key. For generating the key I am using next
>> code:
>>
>> public class SecretKeyProducer {
>>
>> @Produces
>> @ApplicationScoped
>> public Key generateJwtSignKey() {
>> return MacProvider.generateKey();
>> }
>>
>> }
>>
>>
>> Then I inject the key in the service responsible to create the token:
>>
>> @Inject
>> Key keyForSigning;
>>
>> public String generateToken(String login) {
>> System.out.println(keyForSigning);
>> final String token =
>> Jwts.builder().setSubject(login).signWith(SignatureAlgorithm.HS256,
>> keyForSigning).compact();
>> return token;
>> }
>>
>>
>> The problem is that next exception is thrown:
>>
>> java.lang.IllegalArgumentException: MAC signatures must be computed and
>> verified using a SecretKey. The specified key of type
>> org.apache.webbeans.custom.security.Key$$OwbNormalScopeProxy0 is not a
>> SecretKey.
>>
>> The problem is that JJWT do an instanceof:
>>
>> public MacSigner(SignatureAlgorithm alg, Key key) {
>> super(alg, key);
>> Assert.isTrue(alg.isHmac(), "The MacSigner only supports HMAC
>> signature algorithms.");
>> if (!(key instanceof SecretKey)) {
>> String msg = "MAC signatures must be computed and verified
>> using a SecretKey. The specified key of " +
>> "type " + key.getClass().getName() + " is not a
>> SecretKey.";
>> throw new IllegalArgumentException(msg);
>> }
>> }
>>
>>
>> So is there a way from CDI point of view to fix this?
>>
>> Thank you very much.
>
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: CDI proxy and instance of
Posted by Uday Gire <ud...@managecat.com>.
Hi Alex
Try to produce SecretKEy not Key
@Produces
@ApplicationScoped
public SecretKEy generate(){
}
@Inject
SecretKey keyforsigning;
Best
Uday
ManageCat, http://www.managecat.com <http://www.managecat.com/>
> On 19 Sep 2015, at 10:33, Alex Soto <as...@gmail.com> wrote:
>
> Hello, I am developing a very simple Java EE application that generates a
> JWT token. Currently I am using JJWT library to generate it. To generate a
> token I need the claims and a key. For generating the key I am using next
> code:
>
> public class SecretKeyProducer {
>
> @Produces
> @ApplicationScoped
> public Key generateJwtSignKey() {
> return MacProvider.generateKey();
> }
>
> }
>
>
> Then I inject the key in the service responsible to create the token:
>
> @Inject
> Key keyForSigning;
>
> public String generateToken(String login) {
> System.out.println(keyForSigning);
> final String token =
> Jwts.builder().setSubject(login).signWith(SignatureAlgorithm.HS256,
> keyForSigning).compact();
> return token;
> }
>
>
> The problem is that next exception is thrown:
>
> java.lang.IllegalArgumentException: MAC signatures must be computed and
> verified using a SecretKey. The specified key of type
> org.apache.webbeans.custom.security.Key$$OwbNormalScopeProxy0 is not a
> SecretKey.
>
> The problem is that JJWT do an instanceof:
>
> public MacSigner(SignatureAlgorithm alg, Key key) {
> super(alg, key);
> Assert.isTrue(alg.isHmac(), "The MacSigner only supports HMAC
> signature algorithms.");
> if (!(key instanceof SecretKey)) {
> String msg = "MAC signatures must be computed and verified
> using a SecretKey. The specified key of " +
> "type " + key.getClass().getName() + " is not a
> SecretKey.";
> throw new IllegalArgumentException(msg);
> }
> }
>
>
> So is there a way from CDI point of view to fix this?
>
> Thank you very much.