Replace existential JwsHeader method arguments in SigningKeyResolverAdapter with something sane

[dwalend]

SigningKeyResolverAdapter uses existential - raw - JwsHeader in its arguments.

My immediate problem is that I can't override those methods in Scala - no way to express the raw type in a way the compiler will swallow.

object ShrineSigningKeyResolver extends SigningKeyResolverAdapter { def resolveSigningKey(header: JwsHeader, claims: Claims):Key = { ... }}

can't be made to compile.

Long-term raw Java types are going to be a source of trouble in Java.

Thanks,

Dave

[dmitriyvolk]

David, did you manage to go around this problem somehow? Thank you!

[dwalend]

I hacked around it with (the only) lump of Java code in SHRINE. It'll likely work for Java through JDK10 and maybe JDK11, but the folks at Oracle do want to change existential types into a compile error. You'll want to fix this (maybe with higher kinded types, which Java can handle, but not gently) eventually. The easiest fix for you might be to remove the type parameter entirely. Groovy doesn't care.

Dave

package net.shrine.dashboard.jwtauth;

import io.jsonwebtoken.Claims; import io.jsonwebtoken.JwsHeader; import io.jsonwebtoken.SigningKeyResolverAdapter;

import java.security.Key;

/**

• SigningKeyResolverBridge is in Java because JwsHeader takes a parameter, but SigningKeyResolverAdapter specifies it as a raw type. *

• @author david

• @since 1.21 */ public class SigningKeyResolverBridge extends SigningKeyResolverAdapter {

  public Key resolveSigningKey(JwsHeader header, Claims claims) { String keyId = header.getKeyId(); return KeySource.keyForString(keyId); } }

[dmitriyvolk]

Thanks, Dave, I ended up doing something very similar. Was easier for me, too, because I didn't have to do anything general-purpose. I only had to provide an interface for resolving the key based on the issuer.

Dmitriy

[lhazlewood]

What is the suggested fix in JJWT for this issue? Without a suggestion or PR, it doesn't seem like there is anything to be done?

[lhazlewood]

Is it to change the method signatures from these:

Key resolveSigningKey(JwsHeader header, Claims claims);
Key resolveSigningKey(JwsHeader header, String plaintext);

to these:

<T extends JwsHeader<T>> Key resolveSigningKey(JwsHeader<T> header, Claims claims);
<T extends JwsHeader<T>> Key resolveSigningKey(JwsHeader<T> header, String plaintext);

?

[dwalend]

That's probably the most type-safe option. Do you care about backwards compatibility?

[lhazlewood]

Yes, but to a slightly lesser degree while we're on 0.x. Once we hit 1.0.0, we'll need to be very strict about semantic versioning.

That said, I don't think this will break anything - at least not in Java. I made the method signature change (didn't change the Adapter at all), rebuilt the entire project, and all tests pass.

[dwalend]

No new warnings even? That's a surprise.

Thanks for making the fix,

Dave

[jjank]

Are you still planning to change the method signature in 1.0.0 @lhazlewood ? It would be great to ditch that @SuppressWarnings( "rawtypes" ) annotation in my code 🙂

[lhazlewood]

Yes, this is still planned for 1.0.0, but we need to finish JWE and JSON (non-compact) serialization first.

[jdussouillez]

Any updates on this ?

[lhazlewood]

Same status as my last comment. 1.0 has been a long time coming, but we are actively working on it.

[lhazlewood]

This has been resolved with the new Locator<Header> and JwtParserBuilder.keyLocator concept that has been merged to master (SigningKeyResolver is now deprecated). This will be released with 0.12.0`