MP-JWT Aug 18 call agenda

[sst...@redhat.com]

14:00 GMT

https://bluejeans.com/2363391609

https://docs.google.com/document/d/13nIVDJ6uxen7d57rxyARX8-vqsf3HTvC6hHnhitGZ0w/edit#

Agenda:

Review the current proposed final API and spec

• microprofile-jwt-auth-1.0-RC4

• microprofile-jwt-auth-api-1.0-RC4-javadoc.jar

• microprofile-jwt-auth-api-1.0-RC4-sources.jar

• Microprofile-jwt-auth-spec.pdf

Discuss the types of ClaimValue injections

• ClaimValue<json-b-type>

• ClaimValue<Optional<json-b-type>

Discuss the exposed token claim types

• Use of Set<String> vs jsonb List<String> for an untyped mapping of a JSON array type (aud, groups claims vs a non-standard array type claim)

• Jsonb does require the ability to bind to any collection, so Set<String> can be required

Discuss the scope of optional Java EE container TCK tests

[David Blevins]

Won’t be able to attend tomorrow’s meeting.  Quick note on this one:

Discuss the types of ClaimValue injections

• ClaimValue<json-b-type>
• ClaimValue<Optional<json-b-type>

I’d love it if we can support straight injection of Optional just like the Config API.  Essentially:

    @Inject

    @Claim(“height”)

    private Optional<Integer> height;

As well, Provider:

    @Inject

    @Claim(“height”)

    private Provider<Integer> height;

Where “Integer” is of course any json-b-type as noted above.

-David

[sst...@redhat.com]

For RequestScoped values, we can't use Optional<?> directly because it's non-proxyable.

Ok on Provider. It looks like this is something that is automatically handled by the CDI implementation and requires nothing extra from an extension/producer methods, so is there really any need to highlight it?

[sst...@redhat.com]

After looking into the use of Provider<Long>, I'm seeing the same issue as with Optional in that this requires a proxyable type if the producer is @RequestScoped. You can work around this by using @Dependent instead, but this opens up the possibility of incorrect usage such as the following:

@Path("/endp")
@ApplicationScoped
public class RolesEndpoint {

...

    @Inject
    @Claim("iat")
    private ClaimValue<Long> issuedAt;
    @Inject
    @Claim("iat")
    private ClaimValue<Long> dupIssuedAt;
    @Inject
    @Claim(standard = Claims.iat)
    private Provider<Long> providerIAT;
    @Inject
    @Claim(standard = Claims.iat)
    private Long longIAT;

...

While the providerIAT.get() value is obtained from the producer method each time, and therefore can be mapped to the current request token value, the longIAT value is bound on the first invocation and never updated after that, so subsequent invocation of the endpoint do not reflect the request token value. So it seems that there is a caveat to supporting the Provider<?> injection type, namely that it requires a @Dependent scope producer that will match the raw type injection site, but that value will not be at request scoped as one may be expecting. 

I suppose you could detect such injection sites and either fail the deployment, or at least issue a warning about the scope mismatch. 

I don't see that the Provider behavior is really well defined in the CDI 1.2 spec, and the behavior I'm seeing is with Weld. I don't see why one cannot use a non-proxyable type when the injection site is using a Provider wrapper. It is the proxy for the type. Are other CDI implementation supporting this with request scoped producers?

I'll raise an issue on this with Antoine, but since this has quirky behavior on the reference implementation, what do you want to suggest as the spec requirement in terms of the injection of the Provider<?> type?

[John D. Ament]

Hi,

Most of the tricks in the config spec work only because its a dependent scoped bean that's getting created (whether via producer or actual bean registration is moot).  I would strongly recommend either using a ClaimValue or Provider, and not using Optional or primitive wrappers/primitives themselves.

You can model ClaimValue after Optional's api contract.

John

[Emily Jiang]

Scott,

According to your question to Weld, I think the issue is that you tried to produce a normal scoped Long. As Long is a final class, it cannot be proxied. Provider<?> is orthogonal to the issue you experienced, right? By the way, in config javadoc, we clearly warned about Optional<?> support. If you don't need to support Optinal<?>, do not go extra miles to do it. +1 on John!

Emily

[David Blevins]

First time noticing Optional is a final type.  Darn.  It would be perfect for @RequestScoped values that may or may not be there.

We should definitely keep Provider because it was introduced for exactly this.

As far as optional, I’m somewhat tempted to say we add a convenience method in ClaimValue to get it as an optional, but not sure it is worth the noise.  Any thoughts?

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/fd6fb127-d1bb-4aeb-a26f-23946684a24e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sst...@redhat.com]

If you want it as an Optional, you can certainly use that as the type in the ClaimValue at the injection site. This is what I was expecting to test in the TCK.

@Inject
@Claim("auth_time")
private ClaimValue<Optional<Long>> authTime;

[John D. Ament]

That makes it very odd to look at.  What I was thinking was

public interface ClaimValue<T> extends Principal {


    public String getName();



    public T getValue();


    void ifPresent(Consumer<T> consumer);


    boolean isPresent();


    ClaimValue<T> filter(Predicate<T> predicate);


    <U> ClaimValue<U> map(Function<T,U> var1);


    T orElse(T instance);
   
    T orElseGet(Supplier<T> supplier);
   
    <X extends Throwable> T orElseThrow(Supplier<X> supplier);
}

This way it can have all of the behaviors of optional, without any impact to changes on the optional signature and a user can just use it without any conversion.

[sst...@redhat.com]

I don't understand the usage of some of these, for example, what is returned from filter(Predicate<T>) when the predicate is false?

We are API final for 1.0, so the most I would want to introduce is a simple accessor as an Optional along the lines of:

public interface ClaimValue<T> extends Principal {

    @Override

    public String getName();

    public T getValue();
    

    public Optional<T> asOptional();
}

[Alasdair Nottingham]

In the interests of getting to completion I would vote for leaving this out for now and just sticking with Provider.

I think it does point to a common issue that we have with multiple specs, so perhaps for MicroProfile 1.3 we could come up with a derivative of Provider that allows for the Optional use cases, but is an interface so can be proxied.

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/44c0c5e4-9e1b-4c5d-b115-00d6ca3ec995%40googlegroups.com.

[John D. Ament]

Agreed.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microprofile@googlegroups.com.

[John D. Ament]

These are all methods from Optional.  I would expect they all behave just like Optional.