Quantcast

Types of Principal object

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Types of Principal object

John Ament

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Romain Manni-Bucau
Hi John,

agree CDI/security integration (mainly through Principal bean) is completely unusable in practise cause Principal type is too simple (name only) and casting is needed in 99.99% of apps. AFAIK It is tracked at https://issues.jboss.org/browse/CDI-597.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Matej Novotny
In reply to this post by John Ament
Hey John,

just to shed some light.
One of the reasons it works this way is because the types the actual Principal has might not be proxyable.
And spec requires all built-in beans to be decorable - e.g. you need them to be proxyable (although the added value of principal decorator is ...eh, disputable at best?).

Therefore, it is safer/viable to create a proxyable wrapper object which implements Principal only and delegetas calls (that's what Weld does).

Otherwise I agree it could be nice to ahve a way to cast the object as the pure Principal interface doesn't help much.

Matej

----- Original Message -----

> From: "John Ament" <[hidden email]>
> To: "cdi-dev" <[hidden email]>
> Sent: Wednesday, April 26, 2017 3:54:57 PM
> Subject: [cdi-dev] Types of Principal object
>
>
>
> Hey guys
>
>
>
>
> I raised a bug against the Weld guys, but think its worth an EG discussion.
> When a Principal object is injected, the only type it has is Principal. It
> does not retain the actual type used at runtime. This threw me off on some
> Keycloak integration I'm working on (in $dayjob). So I was wondering, is
> this expected from our POV or should it retain the types of the actual
> runtime instance?
>
>
>
>
> John
>
>
>
>
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the sender
> immediately by return e-mail, delete this message, and destroy all physical
> and electronic copies. Thank you.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
In reply to this post by John Ament
Hi,

We discussed this very issue in the Security API EG as well. In the Security API the actual type *MUST* be retained as per the spec definition.

The problem in CDI, at least in Weld, is that a proxy is injected. This happens via the build-in bean "PrincipalBean extends AbstractEEBean", where AbstractEEBean does:

public abstract class AbstractEEBean<T> extends AbstractStaticallyDecorableBuiltInBean<T> {

    private final T proxy;

    protected AbstractEEBean(Class<T> type, Callable<T> callable, BeanManagerImpl beanManager) {
        super(beanManager, type);
        this.proxy = new ProxyFactory<T>(beanManager.getContextId(), type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new CallableMethodHandler(callable)));
    }
    // ...
}

I'm not even sure if it's possible to downcast the proxy to the required runtime type.

Also note that the Principal can change during the request. The simplest case is when during an http request HttpServletRequest#logout is called.

Kind regards,
Arjan Tijms




On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]> wrote:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
In reply to this post by Romain Manni-Bucau
P.s. slightly offtopic for CDI spec itself, but:

A small workaround is to @Inject SecurityContext context; and then:

MyPrincipal principal = (MyPrincipal ) context.getCallerPrincipal();

Thinking of it, maybe I can make the getCallerPrincipal() a generic method, so one can do:

MyPrincipal principal = context.getCallerPrincipal();

Kind regards,
Arjan Tijms






On Wed, Apr 26, 2017 at 4:38 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hi John,

agree CDI/security integration (mainly through Principal bean) is completely unusable in practise cause Principal type is too simple (name only) and casting is needed in 99.99% of apps. AFAIK It is tracked at https://issues.jboss.org/browse/CDI-597.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Romain Manni-Bucau
Doesnt have to work, works recently with tomcat cause was poorly usable but you can still get a "limited" Principal doing that :(

Only portable working case i saw was a filter wrapping the request and overriding the get principal method but you need to access the *right* request


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-04-26 17:14 GMT+02:00 arjan tijms <[hidden email]>:
P.s. slightly offtopic for CDI spec itself, but:

A small workaround is to @Inject SecurityContext context; and then:

MyPrincipal principal = (MyPrincipal ) context.getCallerPrincipal();

Thinking of it, maybe I can make the getCallerPrincipal() a generic method, so one can do:

MyPrincipal principal = context.getCallerPrincipal();

Kind regards,
Arjan Tijms






On Wed, Apr 26, 2017 at 4:38 PM, Romain Manni-Bucau <[hidden email]> wrote:
Hi John,

agree CDI/security integration (mainly through Principal bean) is completely unusable in practise cause Principal type is too simple (name only) and casting is needed in 99.99% of apps. AFAIK It is tracked at https://issues.jboss.org/browse/CDI-597.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Romain Manni-Bucau
In reply to this post by arjan tijms
that's why security API needs a more typed API acting as an handler and not as a contextual instance, it would allow to unwrap the actual instance (like most specs do) but at CDI level it should also be possible. If not we have this built-in bean never working until you add another not mandatory spec - for CDI level. In other words either Principal is removed from CDI spec or it stays but it should be extended to be made usable IMHO.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

We discussed this very issue in the Security API EG as well. In the Security API the actual type *MUST* be retained as per the spec definition.

The problem in CDI, at least in Weld, is that a proxy is injected. This happens via the build-in bean "PrincipalBean extends AbstractEEBean", where AbstractEEBean does:

public abstract class AbstractEEBean<T> extends AbstractStaticallyDecorableBuiltInBean<T> {

    private final T proxy;

    protected AbstractEEBean(Class<T> type, Callable<T> callable, BeanManagerImpl beanManager) {
        super(beanManager, type);
        this.proxy = new ProxyFactory<T>(beanManager.getContextId(), type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new CallableMethodHandler(callable)));
    }
    // ...
}

I'm not even sure if it's possible to downcast the proxy to the required runtime type.

Also note that the Principal can change during the request. The simplest case is when during an http request HttpServletRequest#logout is called.

Kind regards,
Arjan Tijms




On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]> wrote:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Werner Keil-2
In reply to this post by John Ament
Seems the title of the thread was also not "reified" in this case.
Sometimes reply just works, but if it was lost, sorry for that.

Werner 



On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <[hidden email]> wrote:
We had similar challenges and discussions even before JSR 363 about knowing what type of quantity you're dealing with types like
Unit<Q extends Quantity<Q>>
I can only confirm Arjan's impression. And I had numerous conversations with Andrew Kennedy, the Chief Architect behind the F# Units of Measurement support and other .NET libraries about it. Where he mentioned shortcomings of the Java language especially the lack of Reified Generics (http://stackoverflow.com/questions/31876372/what-is-reification), which C#, F# or other .NET languages got, but Java won't at least not until Java 10, 11 or even later.

I tried a lot between 2010 and now but so far none of these Reflection tricks and approaches were stable enough, so not sure, if it'll work any better in this case (unless you implement CDI in C#;-)

Werner


On Wed, Apr 26, 2017 at 5:29 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Types of Principal object (John Ament)
   2. Re: Types of Principal object (Romain Manni-Bucau)
   3. Re: Types of Principal object (Matej Novotny)
   4. Re: Types of Principal object (arjan tijms)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Apr 2017 13:54:57 +0000
From: John Ament <[hidden email]>
Subject: [cdi-dev] Types of Principal object
To: cdi-dev <[hidden email]>
Message-ID:
        <[hidden email]>

Content-Type: text/plain; charset="iso-8859-1"

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John

________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/b6740722/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 26 Apr 2017 16:38:01 +0200
From: Romain Manni-Bucau <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: John Ament <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CACLE=7N=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi John,

agree CDI/security integration (mainly through Principal bean) is
completely unusable in practise cause Principal type is too simple (name
only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
https://issues.jboss.org/browse/CDI-597.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:

> Hey guys
>
>
> I raised a bug against the Weld guys, but think its worth an EG
> discussion.  When a Principal object is injected, the only type it has is
> Principal.  It does not retain the actual type used at runtime.  This threw
> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
> wondering, is this expected from our POV or should it retain the types of
> the actual runtime instance?
>
>
> John
>
> ------------------------------
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this message, and destroy all
> physical and electronic copies. Thank you.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/19976ebd/attachment-0001.html

------------------------------

Message: 3
Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
From: Matej Novotny <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: John Ament <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset=utf-8

Hey John,

just to shed some light.
One of the reasons it works this way is because the types the actual Principal has might not be proxyable.
And spec requires all built-in beans to be decorable - e.g. you need them to be proxyable (although the added value of principal decorator is ...eh, disputable at best?).

Therefore, it is safer/viable to create a proxyable wrapper object which implements Principal only and delegetas calls (that's what Weld does).

Otherwise I agree it could be nice to ahve a way to cast the object as the pure Principal interface doesn't help much.

Matej

----- Original Message -----
> From: "John Ament" <[hidden email]>
> To: "cdi-dev" <[hidden email]>
> Sent: Wednesday, April 26, 2017 3:54:57 PM
> Subject: [cdi-dev] Types of Principal object
>
>
>
> Hey guys
>
>
>
>
> I raised a bug against the Weld guys, but think its worth an EG discussion.
> When a Principal object is injected, the only type it has is Principal. It
> does not retain the actual type used at runtime. This threw me off on some
> Keycloak integration I'm working on (in $dayjob). So I was wondering, is
> this expected from our POV or should it retain the types of the actual
> runtime instance?
>
>
>
>
> John
>
>
>
>
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the sender
> immediately by return e-mail, delete this message, and destroy all physical
> and electronic copies. Thank you.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.


------------------------------

Message: 4
Date: Wed, 26 Apr 2017 17:11:11 +0200
From: arjan tijms <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: John Ament <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

We discussed this very issue in the Security API EG as well. In the
Security API the actual type *MUST* be retained as per the spec definition.

The problem in CDI, at least in Weld, is that a proxy is injected. This
happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
AbstractEEBean does:

public abstract class AbstractEEBean<T> extends
AbstractStaticallyDecorableBuiltInBean<T> {

    private final T proxy;

    protected AbstractEEBean(Class<T> type, Callable<T> callable,
BeanManagerImpl beanManager) {
        super(beanManager, type);
        this.proxy = new ProxyFactory<T>(beanManager.getContextId(), type,
getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
CallableMethodHandler(callable)));
    }
    // ...
}

I'm not even sure if it's possible to downcast the proxy to the required
runtime type.

Also note that the Principal can change during the request. The simplest
case is when during an http request HttpServletRequest#logout is called.

Kind regards,
Arjan Tijms




On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]>
wrote:

> Hey guys
>
>
> I raised a bug against the Weld guys, but think its worth an EG
> discussion.  When a Principal object is injected, the only type it has is
> Principal.  It does not retain the actual type used at runtime.  This threw
> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
> wondering, is this expected from our POV or should it retain the types of
> the actual runtime instance?
>
>
> John
>
> ------------------------------
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this message, and destroy all
> physical and electronic copies. Thank you.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/206ff811/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 77, Issue 8
**************************************



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
In reply to this post by Matej Novotny
Hi,

On Wed, Apr 26, 2017 at 4:48 PM, Matej Novotny <[hidden email]> wrote:
And spec requires all built-in beans to be decorable - e.g. you need them to be proxyable (although the added value of principal decorator is ...eh, disputable at best?).

That would be kinda disputable indeed :O
 
Therefore, it is safer/viable to create a proxyable wrapper object which implements Principal only and delegetas calls (that's what Weld does).

As i mentioned, the proxy has to be there as just injecting a non-proxy Principal would not work correctly. If a logout call is done, the injected Principal would still be the principal that it was before, let alone what happens if the Principal is inject in application scoped beans...

Kind regards,
Arjan Tijms

 

Otherwise I agree it could be nice to ahve a way to cast the object as the pure Principal interface doesn't help much.

Matej

----- Original Message -----
> From: "John Ament" <[hidden email]>
> To: "cdi-dev" <[hidden email]>
> Sent: Wednesday, April 26, 2017 3:54:57 PM
> Subject: [cdi-dev] Types of Principal object
>
>
>
> Hey guys
>
>
>
>
> I raised a bug against the Weld guys, but think its worth an EG discussion.
> When a Principal object is injected, the only type it has is Principal. It
> does not retain the actual type used at runtime. This threw me off on some
> Keycloak integration I'm working on (in $dayjob). So I was wondering, is
> this expected from our POV or should it retain the types of the actual
> runtime instance?
>
>
>
>
> John
>
>
>
>
> NOTICE: This e-mail message and any attachments may contain confidential,
> proprietary, and/or privileged information which should be treated
> accordingly. If you are not the intended recipient, please notify the sender
> immediately by return e-mail, delete this message, and destroy all physical
> and electronic copies. Thank you.
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code
> under the Apache License, Version 2
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other intellectual
> property rights inherent in such information.
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
In reply to this post by Romain Manni-Bucau
Hi,

On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <[hidden email]> wrote:
that's why security API needs a more typed API acting as an handler and not as a contextual instance, it would allow to unwrap the actual instance (like most specs do)

I think that would require a new Principal type, which can be done, but who's going to put time into it to discuss it, spec it, implement it, etc?

Also, the difference with the current situation is not that much then. 

Extended Principal:


@Inject CallerPrincipal callerPrincipal;

...

MyPrincipal myPrincipal = callerPrincipal.unwrap();


vs


Security context:

@Inject SecurityContext securityContext;

...

MyPrincipal myPrincipal = securityContext.getCallerPrincipal();

Spot the differences ;)

 
In other words either Principal is removed from CDI spec

I think this should be done anyway. The build-in bean for Principal would be more at home with the Security API spec. I would be happy to take it in ;)

(likewise, the build-in bean for HttpServletRequest etc should be with the Servlet spec)

 
or it stays but it should be extended to be made usable IMHO.

What CDI could provide and which has been discussed before, is a method to get the real bean from a proxy. E.g.

@Inject CallerPrincipal callerPrincipal;
@Inject BeanManager beanManager;

...

MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);

Kind regards,
Arjan Tijms


 


 


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

We discussed this very issue in the Security API EG as well. In the Security API the actual type *MUST* be retained as per the spec definition.

The problem in CDI, at least in Weld, is that a proxy is injected. This happens via the build-in bean "PrincipalBean extends AbstractEEBean", where AbstractEEBean does:

public abstract class AbstractEEBean<T> extends AbstractStaticallyDecorableBuiltInBean<T> {

    private final T proxy;

    protected AbstractEEBean(Class<T> type, Callable<T> callable, BeanManagerImpl beanManager) {
        super(beanManager, type);
        this.proxy = new ProxyFactory<T>(beanManager.getContextId(), type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new CallableMethodHandler(callable)));
    }
    // ...
}

I'm not even sure if it's possible to downcast the proxy to the required runtime type.

Also note that the Principal can change during the request. The simplest case is when during an http request HttpServletRequest#logout is called.

Kind regards,
Arjan Tijms




On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]> wrote:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Romain Manni-Bucau


2017-04-26 18:07 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <[hidden email]> wrote:
that's why security API needs a more typed API acting as an handler and not as a contextual instance, it would allow to unwrap the actual instance (like most specs do)

I think that would require a new Principal type, which can be done, but who's going to put time into it to discuss it, spec it, implement it, etc?

Also, the difference with the current situation is not that much then. 

Extended Principal:


@Inject CallerPrincipal callerPrincipal;

...

MyPrincipal myPrincipal = callerPrincipal.unwrap();

Was more thinking about:

MyPrincipal myPrincipal = callerPrincipal.unwrap(MyPrincipal.class);
 


vs


Security context:

@Inject SecurityContext securityContext;

...

MyPrincipal myPrincipal = securityContext.getCallerPrincipal();

Spot the differences ;)

Here you can get a PrincipalFacade which limits MyPrincipal to getName() only, this is perfectly valid per spec.
 

 
In other words either Principal is removed from CDI spec

I think this should be done anyway. The build-in bean for Principal would be more at home with the Security API spec. I would be happy to take it in ;)

(likewise, the build-in bean for HttpServletRequest etc should be with the Servlet spec)

 
or it stays but it should be extended to be made usable IMHO.

What CDI could provide and which has been discussed before, is a method to get the real bean from a proxy. E.g.

@Inject CallerPrincipal callerPrincipal;
@Inject BeanManager beanManager;

...

MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);

Well this would assume we can do it for all beans and a lot of cases would be problematic cause it is just not doable :s...but would help if we find a compromise for other beans too :)
 

Kind regards,
Arjan Tijms


 


 


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | JavaEE Factory

2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

We discussed this very issue in the Security API EG as well. In the Security API the actual type *MUST* be retained as per the spec definition.

The problem in CDI, at least in Weld, is that a proxy is injected. This happens via the build-in bean "PrincipalBean extends AbstractEEBean", where AbstractEEBean does:

public abstract class AbstractEEBean<T> extends AbstractStaticallyDecorableBuiltInBean<T> {

    private final T proxy;

    protected AbstractEEBean(Class<T> type, Callable<T> callable, BeanManagerImpl beanManager) {
        super(beanManager, type);
        this.proxy = new ProxyFactory<T>(beanManager.getContextId(), type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new CallableMethodHandler(callable)));
    }
    // ...
}

I'm not even sure if it's possible to downcast the proxy to the required runtime type.

Also note that the Principal can change during the request. The simplest case is when during an http request HttpServletRequest#logout is called.

Kind regards,
Arjan Tijms




On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]> wrote:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.




_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Werner Keil-2
In reply to this post by John Ament
Not sure, if I follow you on that?

java.security.Principal is not part of the CDI spec at all and only used by a special subclass of
AbstractEEBean<T>

The problem seems the generic T which Java at this point is unable to know about at runtime.

It makes no difference, if you had
PrincipalBean extends AbstractEEBean<Principal>
or a
StringBean extends AbstractBuiltInBean<String>

Even created a JUnit test in

https://github.com/unitsofmeasurement/uom-se/blob/master/src/test/java/tec/uom/se/AbsUnitTest.java

Which under Java 8 returns

"java.lang.reflect.TypeVariable<D>"

No sign of "Length" which is what you'd hoped for (maybe we did not dig deep enough, maybe it won't work until a future Java version?)


Werner 



On Wed, Apr 26, 2017 at 5:46 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Types of Principal object (Romain Manni-Bucau)
   2. Re: Types of Principal object (Werner Keil)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Apr 2017 17:41:08 +0200
From: Romain Manni-Bucau <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: arjan tijms <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=[hidden email]>
Content-Type: text/plain; charset="utf-8"

that's why security API needs a more typed API acting as an handler and not
as a contextual instance, it would allow to unwrap the actual instance
(like most specs do) but at CDI level it should also be possible. If not we
have this built-in bean never working until you add another not mandatory
spec - for CDI level. In other words either Principal is removed from CDI
spec or it stays but it should be extended to be made usable IMHO.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:

> Hi,
>
> We discussed this very issue in the Security API EG as well. In the
> Security API the actual type *MUST* be retained as per the spec definition.
>
> The problem in CDI, at least in Weld, is that a proxy is injected. This
> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
> AbstractEEBean does:
>
> public abstract class AbstractEEBean<T> extends
> AbstractStaticallyDecorableBuiltInBean<T> {
>
>     private final T proxy;
>
>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
> BeanManagerImpl beanManager) {
>         super(beanManager, type);
>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
> CallableMethodHandler(callable)));
>     }
>     // ...
> }
>
> I'm not even sure if it's possible to downcast the proxy to the required
> runtime type.
>
> Also note that the Principal can change during the request. The simplest
> case is when during an http request HttpServletRequest#logout is called.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]>
> wrote:
>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ------------------------------
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ad930662/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 26 Apr 2017 17:44:04 +0200
From: Werner Keil <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: cdi-dev <[hidden email]>
Message-ID:
        <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Seems the title of the thread was also not "reified" in this case.
Sometimes reply just works, but if it was lost, sorry for that.

Werner


On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <[hidden email]> wrote:

> We had similar challenges and discussions even before JSR 363 about
> knowing what type of quantity you're dealing with types like
>
> Unit<Q extends Quantity <http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/Quantity.html><Q>>
>
> I can only confirm Arjan's impression. And I had numerous conversations
> with Andrew Kennedy, the Chief Architect behind the F# Units of Measurement
> support and other .NET libraries about it. Where he mentioned shortcomings
> of the Java language especially the lack of Reified Generics (
> http://stackoverflow.com/questions/31876372/what-is-reification), which
> C#, F# or other .NET languages got, but Java won't at least not until Java
> 10, 11 or even later.
>
> I tried a lot between 2010 and now but so far none of these Reflection
> tricks and approaches were stable enough, so not sure, if it'll work any
> better in this case (unless you implement CDI in C#;-)
>
> Werner
>
>
> On Wed, Apr 26, 2017 at 5:29 PM, <[hidden email]> wrote:
>
>> Send cdi-dev mailing list submissions to
>>         [hidden email]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>> or, via email, send a message with subject or body 'help' to
>>         [hidden email]
>>
>> You can reach the person managing the list at
>>         [hidden email]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cdi-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Types of Principal object (John Ament)
>>    2. Re: Types of Principal object (Romain Manni-Bucau)
>>    3. Re: Types of Principal object (Matej Novotny)
>>    4. Re: Types of Principal object (arjan tijms)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 26 Apr 2017 13:54:57 +0000
>> From: John Ament <[hidden email]>
>> Subject: [cdi-dev] Types of Principal object
>> To: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CY4PR04MB048607BF779F8680ED5CE[hidden email]
>> 04.prod.outlook.com>
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ________________________________
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/b6740722/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 26 Apr 2017 16:38:01 +0200
>> From: Romain Manni-Bucau <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CACLE=7N=[hidden email]
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi John,
>>
>> agree CDI/security integration (mainly through Principal bean) is
>> completely unusable in practise cause Principal type is too simple (name
>> only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
>> https://issues.jboss.org/browse/CDI-597.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/19976ebd/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
>> From: Matej Novotny <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <[hidden email]>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hey John,
>>
>> just to shed some light.
>> One of the reasons it works this way is because the types the actual
>> Principal has might not be proxyable.
>> And spec requires all built-in beans to be decorable - e.g. you need them
>> to be proxyable (although the added value of principal decorator is ...eh,
>> disputable at best?).
>>
>> Therefore, it is safer/viable to create a proxyable wrapper object which
>> implements Principal only and delegetas calls (that's what Weld does).
>>
>> Otherwise I agree it could be nice to ahve a way to cast the object as
>> the pure Principal interface doesn't help much.
>>
>> Matej
>>
>> ----- Original Message -----
>> > From: "John Ament" <[hidden email]>
>> > To: "cdi-dev" <[hidden email]>
>> > Sent: Wednesday, April 26, 2017 3:54:57 PM
>> > Subject: [cdi-dev] Types of Principal object
>> >
>> >
>> >
>> > Hey guys
>> >
>> >
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> discussion.
>> > When a Principal object is injected, the only type it has is Principal.
>> It
>> > does not retain the actual type used at runtime. This threw me off on
>> some
>> > Keycloak integration I'm working on (in $dayjob). So I was wondering, is
>> > this expected from our POV or should it retain the types of the actual
>> > runtime instance?
>> >
>> >
>> >
>> >
>> > John
>> >
>> >
>> >
>> >
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> sender
>> > immediately by return e-mail, delete this message, and destroy all
>> physical
>> > and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> code
>> > under the Apache License, Version 2
>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> > provided on this list, the provider waives all patent and other
>> intellectual
>> > property rights inherent in such information.
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 26 Apr 2017 17:11:11 +0200
>> From: arjan tijms <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA@mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> We discussed this very issue in the Security API EG as well. In the
>> Security API the actual type *MUST* be retained as per the spec
>> definition.
>>
>> The problem in CDI, at least in Weld, is that a proxy is injected. This
>> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>> where
>> AbstractEEBean does:
>>
>> public abstract class AbstractEEBean<T> extends
>> AbstractStaticallyDecorableBuiltInBean<T> {
>>
>>     private final T proxy;
>>
>>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>> BeanManagerImpl beanManager) {
>>         super(beanManager, type);
>>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>> type,
>> getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
>> CallableMethodHandler(callable)));
>>     }
>>     // ...
>> }
>>
>> I'm not even sure if it's possible to downcast the proxy to the required
>> runtime type.
>>
>> Also note that the Principal can change during the request. The simplest
>> case is when during an http request HttpServletRequest#logout is called.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]
>> >
>> wrote:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/206ff811/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html).  For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>> End of cdi-dev Digest, Vol 77, Issue 8
>> **************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ebea1962/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 77, Issue 10
***************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Werner Keil-2
In reply to this post by John Ament
Btw. I think some aspects of this thread seem a little off-topic or more specific to the JSR 375 list instead (or at least it would be good to CC that one for detailed java.security discussions rather than if a generic type works or not)

Werner



On Wed, Apr 26, 2017 at 6:11 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Types of Principal object (arjan tijms)
   2. Re: Types of Principal object (arjan tijms)
   3. Re: Types of Principal object (Romain Manni-Bucau)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Apr 2017 18:00:40 +0200
From: arjan tijms <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: Matej Novotny <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CAE=-AhBp8cLUxWOpnT=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

On Wed, Apr 26, 2017 at 4:48 PM, Matej Novotny <[hidden email]> wrote:

> And spec requires all built-in beans to be decorable - e.g. you need them
> to be proxyable (although the added value of principal decorator is ...eh,
> disputable at best?).
>

That would be kinda disputable indeed :O


> Therefore, it is safer/viable to create a proxyable wrapper object which
> implements Principal only and delegetas calls (that's what Weld does).
>

As i mentioned, the proxy has to be there as just injecting a non-proxy
Principal would not work correctly. If a logout call is done, the injected
Principal would still be the principal that it was before, let alone what
happens if the Principal is inject in application scoped beans...

Kind regards,
Arjan Tijms



>
> Otherwise I agree it could be nice to ahve a way to cast the object as the
> pure Principal interface doesn't help much.
>
> Matej
>
> ----- Original Message -----
> > From: "John Ament" <[hidden email]>
> > To: "cdi-dev" <[hidden email]>
> > Sent: Wednesday, April 26, 2017 3:54:57 PM
> > Subject: [cdi-dev] Types of Principal object
> >
> >
> >
> > Hey guys
> >
> >
> >
> >
> > I raised a bug against the Weld guys, but think its worth an EG
> discussion.
> > When a Principal object is injected, the only type it has is Principal.
> It
> > does not retain the actual type used at runtime. This threw me off on
> some
> > Keycloak integration I'm working on (in $dayjob). So I was wondering, is
> > this expected from our POV or should it retain the types of the actual
> > runtime instance?
> >
> >
> >
> >
> > John
> >
> >
> >
> >
> > NOTICE: This e-mail message and any attachments may contain confidential,
> > proprietary, and/or privileged information which should be treated
> > accordingly. If you are not the intended recipient, please notify the
> sender
> > immediately by return e-mail, delete this message, and destroy all
> physical
> > and electronic copies. Thank you.
> >
> > _______________________________________________
> > cdi-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code
> > under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> intellectual
> > property rights inherent in such information.
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/1b8d735a/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 26 Apr 2017 18:07:52 +0200
From: arjan tijms <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: Romain Manni-Bucau <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CAE=-[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <[hidden email]>
wrote:

> that's why security API needs a more typed API acting as an handler and
> not as a contextual instance, it would allow to unwrap the actual instance
> (like most specs do)
>

I think that would require a new Principal type, which can be done, but
who's going to put time into it to discuss it, spec it, implement it, etc?

Also, the difference with the current situation is not that much then.

Extended Principal:


@Inject CallerPrincipal callerPrincipal;

...

MyPrincipal myPrincipal = callerPrincipal.unwrap();


vs


Security context:

@Inject SecurityContext securityContext;

...

MyPrincipal myPrincipal = securityContext.getCallerPrincipal();

Spot the differences ;)



> In other words either Principal is removed from CDI spec
>

I think this should be done anyway. The build-in bean for Principal would
be more at home with the Security API spec. I would be happy to take it in
;)

(likewise, the build-in bean for HttpServletRequest etc should be with the
Servlet spec)



> or it stays but it should be extended to be made usable IMHO.
>

What CDI could provide and which has been discussed before, is a method to
get the real bean from a proxy. E.g.

@Inject CallerPrincipal callerPrincipal;
@Inject BeanManager beanManager;

...

MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);

Kind regards,
Arjan Tijms







>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
>
>> Hi,
>>
>> We discussed this very issue in the Security API EG as well. In the
>> Security API the actual type *MUST* be retained as per the spec definition.
>>
>> The problem in CDI, at least in Weld, is that a proxy is injected. This
>> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
>> AbstractEEBean does:
>>
>> public abstract class AbstractEEBean<T> extends
>> AbstractStaticallyDecorableBuiltInBean<T> {
>>
>>     private final T proxy;
>>
>>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>> BeanManagerImpl beanManager) {
>>         super(beanManager, type);
>>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type,
>> new CallableMethodHandler(callable)));
>>     }
>>     // ...
>> }
>>
>> I'm not even sure if it's possible to downcast the proxy to the required
>> runtime type.
>>
>> Also note that the Principal can change during the request. The simplest
>> case is when during an http request HttpServletRequest#logout is called.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]
>> > wrote:
>>
>>> Hey guys
>>>
>>>
>>> I raised a bug against the Weld guys, but think its worth an EG
>>> discussion.  When a Principal object is injected, the only type it has is
>>> Principal.  It does not retain the actual type used at runtime.  This threw
>>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>>> wondering, is this expected from our POV or should it retain the types of
>>> the actual runtime instance?
>>>
>>>
>>> John
>>>
>>> ------------------------------
>>> NOTICE: This e-mail message and any attachments may contain
>>> confidential, proprietary, and/or privileged information which should be
>>> treated accordingly. If you are not the intended recipient, please notify
>>> the sender immediately by return e-mail, delete this message, and destroy
>>> all physical and electronic copies. Thank you.
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (http://www.apache.org/license
>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>>> provider waives all patent and other intellectual property rights inherent
>>> in such information.
>>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/9cd63650/attachment-0001.html

------------------------------

Message: 3
Date: Wed, 26 Apr 2017 18:10:10 +0200
From: Romain Manni-Bucau <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: arjan tijms <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CACLE=[hidden email]>
Content-Type: text/plain; charset="utf-8"

2017-04-26 18:07 GMT+02:00 arjan tijms <[hidden email]>:

> Hi,
>
> On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <[hidden email]
> > wrote:
>
>> that's why security API needs a more typed API acting as an handler and
>> not as a contextual instance, it would allow to unwrap the actual instance
>> (like most specs do)
>>
>
> I think that would require a new Principal type, which can be done, but
> who's going to put time into it to discuss it, spec it, implement it, etc?
>
> Also, the difference with the current situation is not that much then.
>
> Extended Principal:
>
>
> @Inject CallerPrincipal callerPrincipal;
>
> ...
>
> MyPrincipal myPrincipal = callerPrincipal.unwrap();
>

Was more thinking about:

MyPrincipal myPrincipal = callerPrincipal.unwrap(MyPrincipal.class);


>
>
> vs
>
>
> Security context:
>
> @Inject SecurityContext securityContext;
>
> ...
>
> MyPrincipal myPrincipal = securityContext.getCallerPrincipal();
>
> Spot the differences ;)
>

Here you can get a PrincipalFacade which limits MyPrincipal to getName()
only, this is perfectly valid per spec.


>
>
>
>> In other words either Principal is removed from CDI spec
>>
>
> I think this should be done anyway. The build-in bean for Principal would
> be more at home with the Security API spec. I would be happy to take it in
> ;)
>
> (likewise, the build-in bean for HttpServletRequest etc should be with the
> Servlet spec)
>
>
>
>> or it stays but it should be extended to be made usable IMHO.
>>
>
> What CDI could provide and which has been discussed before, is a method to
> get the real bean from a proxy. E.g.
>
> @Inject CallerPrincipal callerPrincipal;
> @Inject BeanManager beanManager;
>
> ...
>
> MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);
>

Well this would assume we can do it for all beans and a lot of cases would
be problematic cause it is just not doable :s...but would help if we find a
compromise for other beans too :)


>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
>>
>>> Hi,
>>>
>>> We discussed this very issue in the Security API EG as well. In the
>>> Security API the actual type *MUST* be retained as per the spec definition.
>>>
>>> The problem in CDI, at least in Weld, is that a proxy is injected. This
>>> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
>>> AbstractEEBean does:
>>>
>>> public abstract class AbstractEEBean<T> extends
>>> AbstractStaticallyDecorableBuiltInBean<T> {
>>>
>>>     private final T proxy;
>>>
>>>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>>> BeanManagerImpl beanManager) {
>>>         super(beanManager, type);
>>>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>>> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type,
>>> new CallableMethodHandler(callable)));
>>>     }
>>>     // ...
>>> }
>>>
>>> I'm not even sure if it's possible to downcast the proxy to the required
>>> runtime type.
>>>
>>> Also note that the Principal can change during the request. The simplest
>>> case is when during an http request HttpServletRequest#logout is called.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <
>>> [hidden email]> wrote:
>>>
>>>> Hey guys
>>>>
>>>>
>>>> I raised a bug against the Weld guys, but think its worth an EG
>>>> discussion.  When a Principal object is injected, the only type it has is
>>>> Principal.  It does not retain the actual type used at runtime.  This threw
>>>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>>>> wondering, is this expected from our POV or should it retain the types of
>>>> the actual runtime instance?
>>>>
>>>>
>>>> John
>>>>
>>>> ------------------------------
>>>> NOTICE: This e-mail message and any attachments may contain
>>>> confidential, proprietary, and/or privileged information which should be
>>>> treated accordingly. If you are not the intended recipient, please notify
>>>> the sender immediately by return e-mail, delete this message, and destroy
>>>> all physical and electronic copies. Thank you.
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code under the Apache License, Version 2 (http://www.apache.org/license
>>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>>>> provider waives all patent and other intellectual property rights inherent
>>>> in such information.
>>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (http://www.apache.org/license
>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>>> provider waives all patent and other intellectual property rights inherent
>>> in such information.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/1afdba6f/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 77, Issue 11
***************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
In reply to this post by Romain Manni-Bucau
Hi,

On Wed, Apr 26, 2017 at 6:10 PM, Romain Manni-Bucau <[hidden email]> wrote:


Security context:

@Inject SecurityContext securityContext;

...

MyPrincipal myPrincipal = securityContext.getCallerPrincipal();

Spot the differences ;)

Here you can get a PrincipalFacade which limits MyPrincipal to getName() only, this is perfectly valid per spec.

Nope, I spec'ed this such that securityContext.getCallerPrincipal() MUST return the *exact* principal type that was set by the authentication mechanism.

If the code in the (user provided) authentication mechanism sets a MyPrincipal, then a MyPrincipal, and only a MyPrincipal must be returned. I'm going to push for a TCK test to be added for this (although I can't guarantee that as it's outside my influence, unfortunately).



 
 
@Inject CallerPrincipal callerPrincipal;
@Inject BeanManager beanManager;

...

MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);

Well this would assume we can do it for all beans and a lot of cases would be problematic cause it is just not doable :s...but would help if we find a compromise for other beans too :)

Perhaps an exception could be thrown if not unwrappable, or an Optional could be returned that would be empty if not unwrappable, etc.

Kind regards,
Arjan Tijms

 
2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

We discussed this very issue in the Security API EG as well. In the Security API the actual type *MUST* be retained as per the spec definition.

The problem in CDI, at least in Weld, is that a proxy is injected. This happens via the build-in bean "PrincipalBean extends AbstractEEBean", where AbstractEEBean does:

public abstract class AbstractEEBean<T> extends AbstractStaticallyDecorableBuiltInBean<T> {

    private final T proxy;

    protected AbstractEEBean(Class<T> type, Callable<T> callable, BeanManagerImpl beanManager) {
        super(beanManager, type);
        this.proxy = new ProxyFactory<T>(beanManager.getContextId(), type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new CallableMethodHandler(callable)));
    }
    // ...
}

I'm not even sure if it's possible to downcast the proxy to the required runtime type.

Also note that the Principal can change during the request. The simplest case is when during an http request HttpServletRequest#logout is called.

Kind regards,
Arjan Tijms




On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]> wrote:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.





_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Romain Manni-Bucau


2017-04-26 18:18 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

On Wed, Apr 26, 2017 at 6:10 PM, Romain Manni-Bucau <[hidden email]> wrote:


Security context:

@Inject SecurityContext securityContext;

...

MyPrincipal myPrincipal = securityContext.getCallerPrincipal();

Spot the differences ;)

Here you can get a PrincipalFacade which limits MyPrincipal to getName() only, this is perfectly valid per spec.

Nope, I spec'ed this such that securityContext.getCallerPrincipal() MUST return the *exact* principal type that was set by the authentication mechanism.

Yep and my statement is still true. You can still wrap the context in a filter and break that so a user can't rely on it.
 

If the code in the (user provided) authentication mechanism sets a MyPrincipal, then a MyPrincipal, and only a MyPrincipal must be returned. I'm going to push for a TCK test to be added for this (although I can't guarantee that as it's outside my influence, unfortunately).



 
 
@Inject CallerPrincipal callerPrincipal;
@Inject BeanManager beanManager;

...

MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);

Well this would assume we can do it for all beans and a lot of cases would be problematic cause it is just not doable :s...but would help if we find a compromise for other beans too :)

Perhaps an exception could be thrown if not unwrappable, or an Optional could be returned that would be empty if not unwrappable, etc.

Think in the related ticket point is exposing a method which would fail often is too risky
 

Kind regards,
Arjan Tijms

 
2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
Hi,

We discussed this very issue in the Security API EG as well. In the Security API the actual type *MUST* be retained as per the spec definition.

The problem in CDI, at least in Weld, is that a proxy is injected. This happens via the build-in bean "PrincipalBean extends AbstractEEBean", where AbstractEEBean does:

public abstract class AbstractEEBean<T> extends AbstractStaticallyDecorableBuiltInBean<T> {

    private final T proxy;

    protected AbstractEEBean(Class<T> type, Callable<T> callable, BeanManagerImpl beanManager) {
        super(beanManager, type);
        this.proxy = new ProxyFactory<T>(beanManager.getContextId(), type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new CallableMethodHandler(callable)));
    }
    // ...
}

I'm not even sure if it's possible to downcast the proxy to the required runtime type.

Also note that the Principal can change during the request. The simplest case is when during an http request HttpServletRequest#logout is called.

Kind regards,
Arjan Tijms




On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]> wrote:

Hey guys


I raised a bug against the Weld guys, but think its worth an EG discussion.  When a Principal object is injected, the only type it has is Principal.  It does not retain the actual type used at runtime.  This threw me off on some Keycloak integration I'm working on (in $dayjob).  So I was wondering, is this expected from our POV or should it retain the types of the actual runtime instance?


John


NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.






_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
On Wed, Apr 26, 2017 at 6:19 PM, Romain Manni-Bucau <[hidden email]> wrote:
Here you can get a PrincipalFacade which limits MyPrincipal to getName() only, this is perfectly valid per spec.

Nope, I spec'ed this such that securityContext.getCallerPrincipal() MUST return the *exact* principal type that was set by the authentication mechanism.

Yep and my statement is still true. You can still wrap the context in a filter and break that so a user can't rely on it.

I'm not sure if I understand that correctly. You can't really wrap the security context in a filter. The security context is a CDI bean, not an instance that's passed along from one filter to the other.

You can decorate the context and then return whatever from the getCallerPrincipal() method, but that doesn't mean the original getCallerPrincipal() method doesn't return what it's spec'ed to return, is it?

Kind regards,
Arjan Tijms

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
In reply to this post by Werner Keil-2
Hi,

On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil <[hidden email]> wrote:
Not sure, if I follow you on that?

java.security.Principal is not part of the CDI spec at all and only used by a special subclass of
AbstractEEBean<T>

I think what Romain intended here is that the build-in Bean<T> for Principal is removed from CDI and moved to e.g. the Java EE Security spec. In case of Weld that would be org.jboss.weld.bean.builtin.ee.PrincipalBean


The Principal type itself is of course not part of CDI, but part of Java SE.

Btw, a CDI extension can easily scan the application for occurrences of Injection Points that have a Principal subtype as their target, and then dynamically add a specific Bean<T> for that. This is what we do in OmniFaces as well.

See



Kind regards,
Arjan Tijms


 


The problem seems the generic T which Java at this point is unable to know about at runtime.

It makes no difference, if you had
PrincipalBean extends AbstractEEBean<Principal>
or a
StringBean extends AbstractBuiltInBean<String>

Even created a JUnit test in

https://github.com/unitsofmeasurement/uom-se/blob/master/src/test/java/tec/uom/se/AbsUnitTest.java

Which under Java 8 returns

"java.lang.reflect.TypeVariable<D>"

No sign of "Length" which is what you'd hoped for (maybe we did not dig deep enough, maybe it won't work until a future Java version?)


Werner 



On Wed, Apr 26, 2017 at 5:46 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Types of Principal object (Romain Manni-Bucau)
   2. Re: Types of Principal object (Werner Keil)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Apr 2017 17:41:08 +0200
From: Romain Manni-Bucau <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: arjan tijms <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=[hidden email]>
Content-Type: text/plain; charset="utf-8"

that's why security API needs a more typed API acting as an handler and not
as a contextual instance, it would allow to unwrap the actual instance
(like most specs do) but at CDI level it should also be possible. If not we
have this built-in bean never working until you add another not mandatory
spec - for CDI level. In other words either Principal is removed from CDI
spec or it stays but it should be extended to be made usable IMHO.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:

> Hi,
>
> We discussed this very issue in the Security API EG as well. In the
> Security API the actual type *MUST* be retained as per the spec definition.
>
> The problem in CDI, at least in Weld, is that a proxy is injected. This
> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
> AbstractEEBean does:
>
> public abstract class AbstractEEBean<T> extends
> AbstractStaticallyDecorableBuiltInBean<T> {
>
>     private final T proxy;
>
>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
> BeanManagerImpl beanManager) {
>         super(beanManager, type);
>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
> CallableMethodHandler(callable)));
>     }
>     // ...
> }
>
> I'm not even sure if it's possible to downcast the proxy to the required
> runtime type.
>
> Also note that the Principal can change during the request. The simplest
> case is when during an http request HttpServletRequest#logout is called.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]>
> wrote:
>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ------------------------------
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ad930662/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 26 Apr 2017 17:44:04 +0200
From: Werner Keil <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: cdi-dev <[hidden email]>
Message-ID:
        <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Seems the title of the thread was also not "reified" in this case.
Sometimes reply just works, but if it was lost, sorry for that.

Werner


On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <[hidden email]> wrote:

> We had similar challenges and discussions even before JSR 363 about
> knowing what type of quantity you're dealing with types like
>
> Unit<Q extends Quantity <http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/Quantity.html><Q>>
>
> I can only confirm Arjan's impression. And I had numerous conversations
> with Andrew Kennedy, the Chief Architect behind the F# Units of Measurement
> support and other .NET libraries about it. Where he mentioned shortcomings
> of the Java language especially the lack of Reified Generics (
> http://stackoverflow.com/questions/31876372/what-is-reification), which
> C#, F# or other .NET languages got, but Java won't at least not until Java
> 10, 11 or even later.
>
> I tried a lot between 2010 and now but so far none of these Reflection
> tricks and approaches were stable enough, so not sure, if it'll work any
> better in this case (unless you implement CDI in C#;-)
>
> Werner
>
>
> On Wed, Apr 26, 2017 at 5:29 PM, <[hidden email]> wrote:
>
>> Send cdi-dev mailing list submissions to
>>         [hidden email]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>> or, via email, send a message with subject or body 'help' to
>>         [hidden email]
>>
>> You can reach the person managing the list at
>>         [hidden email]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cdi-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Types of Principal object (John Ament)
>>    2. Re: Types of Principal object (Romain Manni-Bucau)
>>    3. Re: Types of Principal object (Matej Novotny)
>>    4. Re: Types of Principal object (arjan tijms)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 26 Apr 2017 13:54:57 +0000
>> From: John Ament <[hidden email]>
>> Subject: [cdi-dev] Types of Principal object
>> To: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CY4PR04MB048607BF779F8680ED5CE53898110@CY4PR04MB0486.namprd
>> 04.prod.outlook.com>
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ________________________________
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/b6740722/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 26 Apr 2017 16:38:01 +0200
>> From: Romain Manni-Bucau <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CACLE=7N=[hidden email]
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi John,
>>
>> agree CDI/security integration (mainly through Principal bean) is
>> completely unusable in practise cause Principal type is too simple (name
>> only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
>> https://issues.jboss.org/browse/CDI-597.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/19976ebd/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
>> From: Matej Novotny <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <[hidden email]>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hey John,
>>
>> just to shed some light.
>> One of the reasons it works this way is because the types the actual
>> Principal has might not be proxyable.
>> And spec requires all built-in beans to be decorable - e.g. you need them
>> to be proxyable (although the added value of principal decorator is ...eh,
>> disputable at best?).
>>
>> Therefore, it is safer/viable to create a proxyable wrapper object which
>> implements Principal only and delegetas calls (that's what Weld does).
>>
>> Otherwise I agree it could be nice to ahve a way to cast the object as
>> the pure Principal interface doesn't help much.
>>
>> Matej
>>
>> ----- Original Message -----
>> > From: "John Ament" <[hidden email]>
>> > To: "cdi-dev" <[hidden email]>
>> > Sent: Wednesday, April 26, 2017 3:54:57 PM
>> > Subject: [cdi-dev] Types of Principal object
>> >
>> >
>> >
>> > Hey guys
>> >
>> >
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> discussion.
>> > When a Principal object is injected, the only type it has is Principal.
>> It
>> > does not retain the actual type used at runtime. This threw me off on
>> some
>> > Keycloak integration I'm working on (in $dayjob). So I was wondering, is
>> > this expected from our POV or should it retain the types of the actual
>> > runtime instance?
>> >
>> >
>> >
>> >
>> > John
>> >
>> >
>> >
>> >
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> sender
>> > immediately by return e-mail, delete this message, and destroy all
>> physical
>> > and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> code
>> > under the Apache License, Version 2
>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> > provided on this list, the provider waives all patent and other
>> intellectual
>> > property rights inherent in such information.
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 26 Apr 2017 17:11:11 +0200
>> From: arjan tijms <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA@mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> We discussed this very issue in the Security API EG as well. In the
>> Security API the actual type *MUST* be retained as per the spec
>> definition.
>>
>> The problem in CDI, at least in Weld, is that a proxy is injected. This
>> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>> where
>> AbstractEEBean does:
>>
>> public abstract class AbstractEEBean<T> extends
>> AbstractStaticallyDecorableBuiltInBean<T> {
>>
>>     private final T proxy;
>>
>>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>> BeanManagerImpl beanManager) {
>>         super(beanManager, type);
>>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>> type,
>> getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
>> CallableMethodHandler(callable)));
>>     }
>>     // ...
>> }
>>
>> I'm not even sure if it's possible to downcast the proxy to the required
>> runtime type.
>>
>> Also note that the Principal can change during the request. The simplest
>> case is when during an http request HttpServletRequest#logout is called.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]
>> >
>> wrote:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/206ff811/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html).  For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>> End of cdi-dev Digest, Vol 77, Issue 8
>> **************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ebea1962/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 77, Issue 10
***************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Werner Keil-2
In reply to this post by John Ament
If Soteria could handle something like that independent of the underlying CDI implementation, it would be great. At the moment it does not seem to require Weld, so unless it redefined the whole "AbstractBean" functionality, not sure, if we can do it there, but I would certainly love to see it there if possible.

Kind Regards,
Werner


On Wed, Apr 26, 2017 at 6:41 PM, arjan tijms <[hidden email]> wrote:
Hi,

On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil <[hidden email]> wrote:
Not sure, if I follow you on that?

java.security.Principal is not part of the CDI spec at all and only used by a special subclass of
AbstractEEBean<T>

I think what Romain intended here is that the build-in Bean<T> for Principal is removed from CDI and moved to e.g. the Java EE Security spec. In case of Weld that would be org.jboss.weld.bean.builtin.ee.PrincipalBean


The Principal type itself is of course not part of CDI, but part of Java SE.

Btw, a CDI extension can easily scan the application for occurrences of Injection Points that have a Principal subtype as their target, and then dynamically add a specific Bean<T> for that. This is what we do in OmniFaces as well.

See



Kind regards,
Arjan Tijms


 


The problem seems the generic T which Java at this point is unable to know about at runtime.

It makes no difference, if you had
PrincipalBean extends AbstractEEBean<Principal>
or a
StringBean extends AbstractBuiltInBean<String>

Even created a JUnit test in

https://github.com/unitsofmeasurement/uom-se/blob/master/src/test/java/tec/uom/se/AbsUnitTest.java

Which under Java 8 returns

"java.lang.reflect.TypeVariable<D>"

No sign of "Length" which is what you'd hoped for (maybe we did not dig deep enough, maybe it won't work until a future Java version?)


Werner 



On Wed, Apr 26, 2017 at 5:46 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Types of Principal object (Romain Manni-Bucau)
   2. Re: Types of Principal object (Werner Keil)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Apr 2017 17:41:08 +0200
From: Romain Manni-Bucau <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: arjan tijms <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=[hidden email]>
Content-Type: text/plain; charset="utf-8"

that's why security API needs a more typed API acting as an handler and not
as a contextual instance, it would allow to unwrap the actual instance
(like most specs do) but at CDI level it should also be possible. If not we
have this built-in bean never working until you add another not mandatory
spec - for CDI level. In other words either Principal is removed from CDI
spec or it stays but it should be extended to be made usable IMHO.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:

> Hi,
>
> We discussed this very issue in the Security API EG as well. In the
> Security API the actual type *MUST* be retained as per the spec definition.
>
> The problem in CDI, at least in Weld, is that a proxy is injected. This
> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
> AbstractEEBean does:
>
> public abstract class AbstractEEBean<T> extends
> AbstractStaticallyDecorableBuiltInBean<T> {
>
>     private final T proxy;
>
>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
> BeanManagerImpl beanManager) {
>         super(beanManager, type);
>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
> CallableMethodHandler(callable)));
>     }
>     // ...
> }
>
> I'm not even sure if it's possible to downcast the proxy to the required
> runtime type.
>
> Also note that the Principal can change during the request. The simplest
> case is when during an http request HttpServletRequest#logout is called.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]>
> wrote:
>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ------------------------------
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ad930662/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 26 Apr 2017 17:44:04 +0200
From: Werner Keil <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: cdi-dev <[hidden email]>
Message-ID:
        <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Seems the title of the thread was also not "reified" in this case.
Sometimes reply just works, but if it was lost, sorry for that.

Werner


On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <[hidden email]> wrote:

> We had similar challenges and discussions even before JSR 363 about
> knowing what type of quantity you're dealing with types like
>
> Unit<Q extends Quantity <http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/Quantity.html><Q>>
>
> I can only confirm Arjan's impression. And I had numerous conversations
> with Andrew Kennedy, the Chief Architect behind the F# Units of Measurement
> support and other .NET libraries about it. Where he mentioned shortcomings
> of the Java language especially the lack of Reified Generics (
> http://stackoverflow.com/questions/31876372/what-is-reification), which
> C#, F# or other .NET languages got, but Java won't at least not until Java
> 10, 11 or even later.
>
> I tried a lot between 2010 and now but so far none of these Reflection
> tricks and approaches were stable enough, so not sure, if it'll work any
> better in this case (unless you implement CDI in C#;-)
>
> Werner
>
>
> On Wed, Apr 26, 2017 at 5:29 PM, <[hidden email]> wrote:
>
>> Send cdi-dev mailing list submissions to
>>         [hidden email]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>> or, via email, send a message with subject or body 'help' to
>>         [hidden email]
>>
>> You can reach the person managing the list at
>>         [hidden email]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cdi-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Types of Principal object (John Ament)
>>    2. Re: Types of Principal object (Romain Manni-Bucau)
>>    3. Re: Types of Principal object (Matej Novotny)
>>    4. Re: Types of Principal object (arjan tijms)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 26 Apr 2017 13:54:57 +0000
>> From: John Ament <[hidden email]>
>> Subject: [cdi-dev] Types of Principal object
>> To: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CY4PR04MB048607BF779F8680ED5[hidden email]d
>> 04.prod.outlook.com>
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ________________________________
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/b6740722/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 26 Apr 2017 16:38:01 +0200
>> From: Romain Manni-Bucau <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CACLE=7N=[hidden email]
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi John,
>>
>> agree CDI/security integration (mainly through Principal bean) is
>> completely unusable in practise cause Principal type is too simple (name
>> only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
>> https://issues.jboss.org/browse/CDI-597.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/19976ebd/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
>> From: Matej Novotny <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <[hidden email]>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hey John,
>>
>> just to shed some light.
>> One of the reasons it works this way is because the types the actual
>> Principal has might not be proxyable.
>> And spec requires all built-in beans to be decorable - e.g. you need them
>> to be proxyable (although the added value of principal decorator is ...eh,
>> disputable at best?).
>>
>> Therefore, it is safer/viable to create a proxyable wrapper object which
>> implements Principal only and delegetas calls (that's what Weld does).
>>
>> Otherwise I agree it could be nice to ahve a way to cast the object as
>> the pure Principal interface doesn't help much.
>>
>> Matej
>>
>> ----- Original Message -----
>> > From: "John Ament" <[hidden email]>
>> > To: "cdi-dev" <[hidden email]>
>> > Sent: Wednesday, April 26, 2017 3:54:57 PM
>> > Subject: [cdi-dev] Types of Principal object
>> >
>> >
>> >
>> > Hey guys
>> >
>> >
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> discussion.
>> > When a Principal object is injected, the only type it has is Principal.
>> It
>> > does not retain the actual type used at runtime. This threw me off on
>> some
>> > Keycloak integration I'm working on (in $dayjob). So I was wondering, is
>> > this expected from our POV or should it retain the types of the actual
>> > runtime instance?
>> >
>> >
>> >
>> >
>> > John
>> >
>> >
>> >
>> >
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> sender
>> > immediately by return e-mail, delete this message, and destroy all
>> physical
>> > and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> code
>> > under the Apache License, Version 2
>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> > provided on this list, the provider waives all patent and other
>> intellectual
>> > property rights inherent in such information.
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 26 Apr 2017 17:11:11 +0200
>> From: arjan tijms <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA@mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> We discussed this very issue in the Security API EG as well. In the
>> Security API the actual type *MUST* be retained as per the spec
>> definition.
>>
>> The problem in CDI, at least in Weld, is that a proxy is injected. This
>> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>> where
>> AbstractEEBean does:
>>
>> public abstract class AbstractEEBean<T> extends
>> AbstractStaticallyDecorableBuiltInBean<T> {
>>
>>     private final T proxy;
>>
>>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>> BeanManagerImpl beanManager) {
>>         super(beanManager, type);
>>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>> type,
>> getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
>> CallableMethodHandler(callable)));
>>     }
>>     // ...
>> }
>>
>> I'm not even sure if it's possible to downcast the proxy to the required
>> runtime type.
>>
>> Also note that the Principal can change during the request. The simplest
>> case is when during an http request HttpServletRequest#logout is called.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]
>> >
>> wrote:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/206ff811/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html).  For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>> End of cdi-dev Digest, Vol 77, Issue 8
>> **************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ebea1962/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 77, Issue 10
***************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

arjan tijms
Hi,

We might do sub-types of Principal, and leave the base Principal at CDI (since we can't change that now in CDI 2.0).

But we are also short of time. I'm not even sure TBH when the deadline for the JSR 375 PR is.

Kind regards,
Arjan Tijms





On Wed, Apr 26, 2017 at 6:51 PM, Werner Keil <[hidden email]> wrote:
If Soteria could handle something like that independent of the underlying CDI implementation, it would be great. At the moment it does not seem to require Weld, so unless it redefined the whole "AbstractBean" functionality, not sure, if we can do it there, but I would certainly love to see it there if possible.

Kind Regards,
Werner


On Wed, Apr 26, 2017 at 6:41 PM, arjan tijms <[hidden email]> wrote:
Hi,

On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil <[hidden email]> wrote:
Not sure, if I follow you on that?

java.security.Principal is not part of the CDI spec at all and only used by a special subclass of
AbstractEEBean<T>

I think what Romain intended here is that the build-in Bean<T> for Principal is removed from CDI and moved to e.g. the Java EE Security spec. In case of Weld that would be org.jboss.weld.bean.builtin.ee.PrincipalBean


The Principal type itself is of course not part of CDI, but part of Java SE.

Btw, a CDI extension can easily scan the application for occurrences of Injection Points that have a Principal subtype as their target, and then dynamically add a specific Bean<T> for that. This is what we do in OmniFaces as well.

See



Kind regards,
Arjan Tijms


 


The problem seems the generic T which Java at this point is unable to know about at runtime.

It makes no difference, if you had
PrincipalBean extends AbstractEEBean<Principal>
or a
StringBean extends AbstractBuiltInBean<String>

Even created a JUnit test in

https://github.com/unitsofmeasurement/uom-se/blob/master/src/test/java/tec/uom/se/AbsUnitTest.java

Which under Java 8 returns

"java.lang.reflect.TypeVariable<D>"

No sign of "Length" which is what you'd hoped for (maybe we did not dig deep enough, maybe it won't work until a future Java version?)


Werner 



On Wed, Apr 26, 2017 at 5:46 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Types of Principal object (Romain Manni-Bucau)
   2. Re: Types of Principal object (Werner Keil)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Apr 2017 17:41:08 +0200
From: Romain Manni-Bucau <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: arjan tijms <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=[hidden email]>
Content-Type: text/plain; charset="utf-8"

that's why security API needs a more typed API acting as an handler and not
as a contextual instance, it would allow to unwrap the actual instance
(like most specs do) but at CDI level it should also be possible. If not we
have this built-in bean never working until you add another not mandatory
spec - for CDI level. In other words either Principal is removed from CDI
spec or it stays but it should be extended to be made usable IMHO.



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:

> Hi,
>
> We discussed this very issue in the Security API EG as well. In the
> Security API the actual type *MUST* be retained as per the spec definition.
>
> The problem in CDI, at least in Weld, is that a proxy is injected. This
> happens via the build-in bean "PrincipalBean extends AbstractEEBean", where
> AbstractEEBean does:
>
> public abstract class AbstractEEBean<T> extends
> AbstractStaticallyDecorableBuiltInBean<T> {
>
>     private final T proxy;
>
>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
> BeanManagerImpl beanManager) {
>         super(beanManager, type);
>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
> CallableMethodHandler(callable)));
>     }
>     // ...
> }
>
> I'm not even sure if it's possible to downcast the proxy to the required
> runtime type.
>
> Also note that the Principal can change during the request. The simplest
> case is when during an http request HttpServletRequest#logout is called.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]>
> wrote:
>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ------------------------------
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ad930662/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 26 Apr 2017 17:44:04 +0200
From: Werner Keil <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: cdi-dev <[hidden email]>
Message-ID:
        <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Seems the title of the thread was also not "reified" in this case.
Sometimes reply just works, but if it was lost, sorry for that.

Werner


On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <[hidden email]> wrote:

> We had similar challenges and discussions even before JSR 363 about
> knowing what type of quantity you're dealing with types like
>
> Unit<Q extends Quantity <http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/Quantity.html><Q>>
>
> I can only confirm Arjan's impression. And I had numerous conversations
> with Andrew Kennedy, the Chief Architect behind the F# Units of Measurement
> support and other .NET libraries about it. Where he mentioned shortcomings
> of the Java language especially the lack of Reified Generics (
> http://stackoverflow.com/questions/31876372/what-is-reification), which
> C#, F# or other .NET languages got, but Java won't at least not until Java
> 10, 11 or even later.
>
> I tried a lot between 2010 and now but so far none of these Reflection
> tricks and approaches were stable enough, so not sure, if it'll work any
> better in this case (unless you implement CDI in C#;-)
>
> Werner
>
>
> On Wed, Apr 26, 2017 at 5:29 PM, <[hidden email]> wrote:
>
>> Send cdi-dev mailing list submissions to
>>         [hidden email]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>> or, via email, send a message with subject or body 'help' to
>>         [hidden email]
>>
>> You can reach the person managing the list at
>>         [hidden email]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cdi-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Types of Principal object (John Ament)
>>    2. Re: Types of Principal object (Romain Manni-Bucau)
>>    3. Re: Types of Principal object (Matej Novotny)
>>    4. Re: Types of Principal object (arjan tijms)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 26 Apr 2017 13:54:57 +0000
>> From: John Ament <[hidden email]>
>> Subject: [cdi-dev] Types of Principal object
>> To: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CY4PR04MB048607BF779F8680ED5[hidden email]d
>> 04.prod.outlook.com>
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hey guys
>>
>>
>> I raised a bug against the Weld guys, but think its worth an EG
>> discussion.  When a Principal object is injected, the only type it has is
>> Principal.  It does not retain the actual type used at runtime.  This threw
>> me off on some Keycloak integration I'm working on (in $dayjob).  So I was
>> wondering, is this expected from our POV or should it retain the types of
>> the actual runtime instance?
>>
>>
>> John
>>
>> ________________________________
>> NOTICE: This e-mail message and any attachments may contain confidential,
>> proprietary, and/or privileged information which should be treated
>> accordingly. If you are not the intended recipient, please notify the
>> sender immediately by return e-mail, delete this message, and destroy all
>> physical and electronic copies. Thank you.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/b6740722/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 26 Apr 2017 16:38:01 +0200
>> From: Romain Manni-Bucau <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CACLE=7N=[hidden email]
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi John,
>>
>> agree CDI/security integration (mainly through Principal bean) is
>> completely unusable in practise cause Principal type is too simple (name
>> only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
>> https://issues.jboss.org/browse/CDI-597.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>
>> 2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/19976ebd/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
>> From: Matej Novotny <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <[hidden email]>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hey John,
>>
>> just to shed some light.
>> One of the reasons it works this way is because the types the actual
>> Principal has might not be proxyable.
>> And spec requires all built-in beans to be decorable - e.g. you need them
>> to be proxyable (although the added value of principal decorator is ...eh,
>> disputable at best?).
>>
>> Therefore, it is safer/viable to create a proxyable wrapper object which
>> implements Principal only and delegetas calls (that's what Weld does).
>>
>> Otherwise I agree it could be nice to ahve a way to cast the object as
>> the pure Principal interface doesn't help much.
>>
>> Matej
>>
>> ----- Original Message -----
>> > From: "John Ament" <[hidden email]>
>> > To: "cdi-dev" <[hidden email]>
>> > Sent: Wednesday, April 26, 2017 3:54:57 PM
>> > Subject: [cdi-dev] Types of Principal object
>> >
>> >
>> >
>> > Hey guys
>> >
>> >
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> discussion.
>> > When a Principal object is injected, the only type it has is Principal.
>> It
>> > does not retain the actual type used at runtime. This threw me off on
>> some
>> > Keycloak integration I'm working on (in $dayjob). So I was wondering, is
>> > this expected from our POV or should it retain the types of the actual
>> > runtime instance?
>> >
>> >
>> >
>> >
>> > John
>> >
>> >
>> >
>> >
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> sender
>> > immediately by return e-mail, delete this message, and destroy all
>> physical
>> > and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> code
>> > under the Apache License, Version 2
>> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> > provided on this list, the provider waives all patent and other
>> intellectual
>> > property rights inherent in such information.
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 26 Apr 2017 17:11:11 +0200
>> From: arjan tijms <[hidden email]>
>> Subject: Re: [cdi-dev] Types of Principal object
>> To: John Ament <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> Message-ID:
>>         <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA@mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> We discussed this very issue in the Security API EG as well. In the
>> Security API the actual type *MUST* be retained as per the spec
>> definition.
>>
>> The problem in CDI, at least in Weld, is that a proxy is injected. This
>> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>> where
>> AbstractEEBean does:
>>
>> public abstract class AbstractEEBean<T> extends
>> AbstractStaticallyDecorableBuiltInBean<T> {
>>
>>     private final T proxy;
>>
>>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>> BeanManagerImpl beanManager) {
>>         super(beanManager, type);
>>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>> type,
>> getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
>> CallableMethodHandler(callable)));
>>     }
>>     // ...
>> }
>>
>> I'm not even sure if it's possible to downcast the proxy to the required
>> runtime type.
>>
>> Also note that the Principal can change during the request. The simplest
>> case is when during an http request HttpServletRequest#logout is called.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <[hidden email]
>> >
>> wrote:
>>
>> > Hey guys
>> >
>> >
>> > I raised a bug against the Weld guys, but think its worth an EG
>> > discussion.  When a Principal object is injected, the only type it has
>> is
>> > Principal.  It does not retain the actual type used at runtime.  This
>> threw
>> > me off on some Keycloak integration I'm working on (in $dayjob).  So I
>> was
>> > wondering, is this expected from our POV or should it retain the types
>> of
>> > the actual runtime instance?
>> >
>> >
>> > John
>> >
>> > ------------------------------
>> > NOTICE: This e-mail message and any attachments may contain
>> confidential,
>> > proprietary, and/or privileged information which should be treated
>> > accordingly. If you are not the intended recipient, please notify the
>> > sender immediately by return e-mail, delete this message, and destroy
>> all
>> > physical and electronic copies. Thank you.
>> >
>> > _______________________________________________
>> > cdi-dev mailing list
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider licenses the
>> > code under the Apache License, Version 2 (http://www.apache.org/
>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>> > the provider waives all patent and other intellectual property rights
>> > inherent in such information.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>> 6/206ff811/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html).  For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>> End of cdi-dev Digest, Vol 77, Issue 8
>> **************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/ebea1962/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 77, Issue 10
***************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.




_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Types of Principal object

Werner Keil-2
In reply to this post by John Ament
JSR 365 is not yet final, the FAB just started yesterday, but it had to be a rather drastic change to still remove it from the CDI 2 Spec and RI, otherwise letting 375 extend it sounds like a good idea.

Werner 



On Wed, Apr 26, 2017 at 6:56 PM, <[hidden email]> wrote:
Send cdi-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Types of Principal object (arjan tijms)


----------------------------------------------------------------------

Message: 1
Date: Wed, 26 Apr 2017 18:56:10 +0200
From: arjan tijms <[hidden email]>
Subject: Re: [cdi-dev] Types of Principal object
To: Werner Keil <[hidden email]>
Cc: cdi-dev <[hidden email]>
Message-ID:
        <CAE=-[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

We might do sub-types of Principal, and leave the base Principal at CDI
(since we can't change that now in CDI 2.0).

But we are also short of time. I'm not even sure TBH when the deadline for
the JSR 375 PR is.

Kind regards,
Arjan Tijms





On Wed, Apr 26, 2017 at 6:51 PM, Werner Keil <[hidden email]> wrote:

> If Soteria could handle something like that independent of the underlying
> CDI implementation, it would be great. At the moment it does not seem to
> require Weld, so unless it redefined the whole "AbstractBean"
> functionality, not sure, if we can do it there, but I would certainly love
> to see it there if possible.
>
> Kind Regards,
> Werner
>
>
> On Wed, Apr 26, 2017 at 6:41 PM, arjan tijms <[hidden email]>
> wrote:
>
>> Hi,
>>
>> On Wed, Apr 26, 2017 at 6:14 PM, Werner Keil <[hidden email]>
>> wrote:
>>
>>> Not sure, if I follow you on that?
>>>
>>> java.security.Principal is not part of the CDI spec at all and only used
>>> by a special subclass of
>>> AbstractEEBean<T>
>>>
>>
>> I think what Romain intended here is that the build-in Bean<T> for
>> Principal is removed from CDI and moved to e.g. the Java EE Security spec.
>> In case of Weld that would be org.jboss.weld.bean.builtin
>> .ee.PrincipalBean
>>
>> (see http://grepcode.com/file/repo1.maven.org/maven2/org.jbo
>> ss.weld.servlet/weld-servlet/2.3.0.Beta3/org/jboss/weld/
>> bean/builtin/ee/PrincipalBean.java#PrincipalBean)
>>
>> The Principal type itself is of course not part of CDI, but part of Java
>> SE.
>>
>> Btw, a CDI extension can easily scan the application for occurrences of
>> Injection Points that have a Principal subtype as their target, and then
>> dynamically add a specific Bean<T> for that. This is what we do in
>> OmniFaces as well.
>>
>> See
>>
>> * Collecting types: https://github.com/omnifaces/omnifaces/blob/develop/
>> src/main/java/org/omnifaces/cdi/param/ParamExtension.java#L61
>>
>> * Adding a Bean<T> for each encountered type: https://github.com/omnif
>> aces/omnifaces/blob/develop/src/main/java/org/omnifaces/
>> cdi/param/ParamExtension.java#L74
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>>
>>>
>>> The problem seems the generic T which Java at this point is unable to
>>> know about at runtime.
>>>
>>> It makes no difference, if you had
>>> PrincipalBean extends AbstractEEBean<Principal>
>>> or a
>>> StringBean extends AbstractBuiltInBean<String>
>>>
>>> Even created a JUnit test in
>>>
>>> https://github.com/unitsofmeasurement/uom-se/blob/master/src
>>> /test/java/tec/uom/se/AbsUnitTest.java
>>>
>>> Which under Java 8 returns
>>>
>>> "java.lang.reflect.TypeVariable<D>"
>>>
>>> No sign of "Length" which is what you'd hoped for (maybe we did not dig
>>> deep enough, maybe it won't work until a future Java version?)
>>>
>>>
>>> Werner
>>>
>>>
>>> On Wed, Apr 26, 2017 at 5:46 PM, <[hidden email]>
>>> wrote:
>>>
>>>> Send cdi-dev mailing list submissions to
>>>>         [hidden email]
>>>>
>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> or, via email, send a message with subject or body 'help' to
>>>>         [hidden email]
>>>>
>>>> You can reach the person managing the list at
>>>>         [hidden email]
>>>>
>>>> When replying, please edit your Subject line so it is more specific
>>>> than "Re: Contents of cdi-dev digest..."
>>>>
>>>>
>>>> Today's Topics:
>>>>
>>>>    1. Re: Types of Principal object (Romain Manni-Bucau)
>>>>    2. Re: Types of Principal object (Werner Keil)
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Wed, 26 Apr 2017 17:41:08 +0200
>>>> From: Romain Manni-Bucau <[hidden email]>
>>>> Subject: Re: [cdi-dev] Types of Principal object
>>>> To: arjan tijms <[hidden email]>
>>>> Cc: cdi-dev <[hidden email]>
>>>> Message-ID:
>>>>         <CACLE=7OK-JWXptMQxM8BUAvE2ab5gOwNiNBHCDbjy=[hidden email]
>>>> ail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> that's why security API needs a more typed API acting as an handler and
>>>> not
>>>> as a contextual instance, it would allow to unwrap the actual instance
>>>> (like most specs do) but at CDI level it should also be possible. If
>>>> not we
>>>> have this built-in bean never working until you add another not
>>>> mandatory
>>>> spec - for CDI level. In other words either Principal is removed from
>>>> CDI
>>>> spec or it stays but it should be extended to be made usable IMHO.
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github <
>>>> https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>>
>>>> 2017-04-26 17:11 GMT+02:00 arjan tijms <[hidden email]>:
>>>>
>>>> > Hi,
>>>> >
>>>> > We discussed this very issue in the Security API EG as well. In the
>>>> > Security API the actual type *MUST* be retained as per the spec
>>>> definition.
>>>> >
>>>> > The problem in CDI, at least in Weld, is that a proxy is injected.
>>>> This
>>>> > happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>>>> where
>>>> > AbstractEEBean does:
>>>> >
>>>> > public abstract class AbstractEEBean<T> extends
>>>> > AbstractStaticallyDecorableBuiltInBean<T> {
>>>> >
>>>> >     private final T proxy;
>>>> >
>>>> >     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>>>> > BeanManagerImpl beanManager) {
>>>> >         super(beanManager, type);
>>>> >         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>>>> > type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type,
>>>> new
>>>> > CallableMethodHandler(callable)));
>>>> >     }
>>>> >     // ...
>>>> > }
>>>> >
>>>> > I'm not even sure if it's possible to downcast the proxy to the
>>>> required
>>>> > runtime type.
>>>> >
>>>> > Also note that the Principal can change during the request. The
>>>> simplest
>>>> > case is when during an http request HttpServletRequest#logout is
>>>> called.
>>>> >
>>>> > Kind regards,
>>>> > Arjan Tijms
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Apr 26, 2017 at 3:54 PM, John Ament <
>>>> [hidden email]>
>>>> > wrote:
>>>> >
>>>> >> Hey guys
>>>> >>
>>>> >>
>>>> >> I raised a bug against the Weld guys, but think its worth an EG
>>>> >> discussion.  When a Principal object is injected, the only type it
>>>> has is
>>>> >> Principal.  It does not retain the actual type used at runtime.
>>>> This threw
>>>> >> me off on some Keycloak integration I'm working on (in $dayjob).  So
>>>> I was
>>>> >> wondering, is this expected from our POV or should it retain the
>>>> types of
>>>> >> the actual runtime instance?
>>>> >>
>>>> >>
>>>> >> John
>>>> >>
>>>> >> ------------------------------
>>>> >> NOTICE: This e-mail message and any attachments may contain
>>>> confidential,
>>>> >> proprietary, and/or privileged information which should be treated
>>>> >> accordingly. If you are not the intended recipient, please notify the
>>>> >> sender immediately by return e-mail, delete this message, and
>>>> destroy all
>>>> >> physical and electronic copies. Thank you.
>>>> >>
>>>> >> _______________________________________________
>>>> >> cdi-dev mailing list
>>>> >> [hidden email]
>>>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> >>
>>>> >> Note that for all code provided on this list, the provider licenses
>>>> the
>>>> >> code under the Apache License, Version 2 (
>>>> http://www.apache.org/license
>>>> >> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>>>> >> provider waives all patent and other intellectual property rights
>>>> inherent
>>>> >> in such information.
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > cdi-dev mailing list
>>>> > [hidden email]
>>>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> >
>>>> > Note that for all code provided on this list, the provider licenses
>>>> the
>>>> > code under the Apache License, Version 2 (http://www.apache.org/
>>>> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
>>>> > the provider waives all patent and other intellectual property rights
>>>> > inherent in such information.
>>>> >
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>>>> 6/ad930662/attachment-0001.html
>>>>
>>>> ------------------------------
>>>>
>>>> Message: 2
>>>> Date: Wed, 26 Apr 2017 17:44:04 +0200
>>>> From: Werner Keil <[hidden email]>
>>>> Subject: Re: [cdi-dev] Types of Principal object
>>>> To: cdi-dev <[hidden email]>
>>>> Message-ID:
>>>>         <CAAGawe1dmVUmgnrnmtV_oS0==fttYOe44ZhG4YfO+yme2=[hidden email]
>>>> ail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> Seems the title of the thread was also not "reified" in this case.
>>>> Sometimes reply just works, but if it was lost, sorry for that.
>>>>
>>>> Werner
>>>>
>>>>
>>>> On Wed, Apr 26, 2017 at 5:41 PM, Werner Keil <[hidden email]>
>>>> wrote:
>>>>
>>>> > We had similar challenges and discussions even before JSR 363 about
>>>> > knowing what type of quantity you're dealing with types like
>>>> >
>>>> > Unit<Q extends Quantity <http://unitsofmeasurement.git
>>>> hub.io/unit-api/site/apidocs/javax/measure/Quantity.html><Q>>
>>>> >
>>>> > I can only confirm Arjan's impression. And I had numerous
>>>> conversations
>>>> > with Andrew Kennedy, the Chief Architect behind the F# Units of
>>>> Measurement
>>>> > support and other .NET libraries about it. Where he mentioned
>>>> shortcomings
>>>> > of the Java language especially the lack of Reified Generics (
>>>> > http://stackoverflow.com/questions/31876372/what-is-reification),
>>>> which
>>>> > C#, F# or other .NET languages got, but Java won't at least not until
>>>> Java
>>>> > 10, 11 or even later.
>>>> >
>>>> > I tried a lot between 2010 and now but so far none of these Reflection
>>>> > tricks and approaches were stable enough, so not sure, if it'll work
>>>> any
>>>> > better in this case (unless you implement CDI in C#;-)
>>>> >
>>>> > Werner
>>>> >
>>>> >
>>>> > On Wed, Apr 26, 2017 at 5:29 PM, <[hidden email]>
>>>> wrote:
>>>> >
>>>> >> Send cdi-dev mailing list submissions to
>>>> >>         [hidden email]
>>>> >>
>>>> >> To subscribe or unsubscribe via the World Wide Web, visit
>>>> >>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> >> or, via email, send a message with subject or body 'help' to
>>>> >>         [hidden email]
>>>> >>
>>>> >> You can reach the person managing the list at
>>>> >>         [hidden email]
>>>> >>
>>>> >> When replying, please edit your Subject line so it is more specific
>>>> >> than "Re: Contents of cdi-dev digest..."
>>>> >>
>>>> >>
>>>> >> Today's Topics:
>>>> >>
>>>> >>    1. Types of Principal object (John Ament)
>>>> >>    2. Re: Types of Principal object (Romain Manni-Bucau)
>>>> >>    3. Re: Types of Principal object (Matej Novotny)
>>>> >>    4. Re: Types of Principal object (arjan tijms)
>>>> >>
>>>> >>
>>>> >> ------------------------------------------------------------
>>>> ----------
>>>> >>
>>>> >> Message: 1
>>>> >> Date: Wed, 26 Apr 2017 13:54:57 +0000
>>>> >> From: John Ament <[hidden email]>
>>>> >> Subject: [cdi-dev] Types of Principal object
>>>> >> To: cdi-dev <[hidden email]>
>>>> >> Message-ID:
>>>> >>         <CY4PR04MB048607BF779F8680ED5CE[hidden email]
>>>> >> 04.prod.outlook.com>
>>>> >>
>>>> >> Content-Type: text/plain; charset="iso-8859-1"
>>>> >>
>>>> >> Hey guys
>>>> >>
>>>> >>
>>>> >> I raised a bug against the Weld guys, but think its worth an EG
>>>> >> discussion.  When a Principal object is injected, the only type it
>>>> has is
>>>> >> Principal.  It does not retain the actual type used at runtime.
>>>> This threw
>>>> >> me off on some Keycloak integration I'm working on (in $dayjob).  So
>>>> I was
>>>> >> wondering, is this expected from our POV or should it retain the
>>>> types of
>>>> >> the actual runtime instance?
>>>> >>
>>>> >>
>>>> >> John
>>>> >>
>>>> >> ________________________________
>>>> >> NOTICE: This e-mail message and any attachments may contain
>>>> confidential,
>>>> >> proprietary, and/or privileged information which should be treated
>>>> >> accordingly. If you are not the intended recipient, please notify the
>>>> >> sender immediately by return e-mail, delete this message, and
>>>> destroy all
>>>> >> physical and electronic copies. Thank you.
>>>> >> -------------- next part --------------
>>>> >> An HTML attachment was scrubbed...
>>>> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>>>> >> 6/b6740722/attachment-0001.html
>>>> >>
>>>> >> ------------------------------
>>>> >>
>>>> >> Message: 2
>>>> >> Date: Wed, 26 Apr 2017 16:38:01 +0200
>>>> >> From: Romain Manni-Bucau <[hidden email]>
>>>> >> Subject: Re: [cdi-dev] Types of Principal object
>>>> >> To: John Ament <[hidden email]>
>>>> >> Cc: cdi-dev <[hidden email]>
>>>> >> Message-ID:
>>>> >>         <CACLE=7N=[hidden email]
>>>> >> ail.com>
>>>> >> Content-Type: text/plain; charset="utf-8"
>>>> >>
>>>> >> Hi John,
>>>> >>
>>>> >> agree CDI/security integration (mainly through Principal bean) is
>>>> >> completely unusable in practise cause Principal type is too simple
>>>> (name
>>>> >> only) and casting is needed in 99.99% of apps. AFAIK It is tracked at
>>>> >> https://issues.jboss.org/browse/CDI-597.
>>>> >>
>>>> >>
>>>> >> Romain Manni-Bucau
>>>> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>>> >> <http://rmannibucau.wordpress.com> | Github <
>>>> >> https://github.com/rmannibucau> |
>>>> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>>> >> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>> >>
>>>> >> 2017-04-26 15:54 GMT+02:00 John Ament <[hidden email]>
>>>> :
>>>> >>
>>>> >> > Hey guys
>>>> >> >
>>>> >> >
>>>> >> > I raised a bug against the Weld guys, but think its worth an EG
>>>> >> > discussion.  When a Principal object is injected, the only type it
>>>> has
>>>> >> is
>>>> >> > Principal.  It does not retain the actual type used at runtime.
>>>> This
>>>> >> threw
>>>> >> > me off on some Keycloak integration I'm working on (in $dayjob).
>>>> So I
>>>> >> was
>>>> >> > wondering, is this expected from our POV or should it retain the
>>>> types
>>>> >> of
>>>> >> > the actual runtime instance?
>>>> >> >
>>>> >> >
>>>> >> > John
>>>> >> >
>>>> >> > ------------------------------
>>>> >> > NOTICE: This e-mail message and any attachments may contain
>>>> >> confidential,
>>>> >> > proprietary, and/or privileged information which should be treated
>>>> >> > accordingly. If you are not the intended recipient, please notify
>>>> the
>>>> >> > sender immediately by return e-mail, delete this message, and
>>>> destroy
>>>> >> all
>>>> >> > physical and electronic copies. Thank you.
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > cdi-dev mailing list
>>>> >> > [hidden email]
>>>> >> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> >> >
>>>> >> > Note that for all code provided on this list, the provider
>>>> licenses the
>>>> >> > code under the Apache License, Version 2 (http://www.apache.org/
>>>> >> > licenses/LICENSE-2.0.html). For all other ideas provided on this
>>>> list,
>>>> >> > the provider waives all patent and other intellectual property
>>>> rights
>>>> >> > inherent in such information.
>>>> >> >
>>>> >> -------------- next part --------------
>>>> >> An HTML attachment was scrubbed...
>>>> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>>>> >> 6/19976ebd/attachment-0001.html
>>>> >>
>>>> >> ------------------------------
>>>> >>
>>>> >> Message: 3
>>>> >> Date: Wed, 26 Apr 2017 10:48:40 -0400 (EDT)
>>>> >> From: Matej Novotny <[hidden email]>
>>>> >> Subject: Re: [cdi-dev] Types of Principal object
>>>> >> To: John Ament <[hidden email]>
>>>> >> Cc: cdi-dev <[hidden email]>
>>>> >> Message-ID:
>>>> >>         <[hidden email]
>>>> >
>>>> >> Content-Type: text/plain; charset=utf-8
>>>> >>
>>>> >> Hey John,
>>>> >>
>>>> >> just to shed some light.
>>>> >> One of the reasons it works this way is because the types the actual
>>>> >> Principal has might not be proxyable.
>>>> >> And spec requires all built-in beans to be decorable - e.g. you need
>>>> them
>>>> >> to be proxyable (although the added value of principal decorator is
>>>> ...eh,
>>>> >> disputable at best?).
>>>> >>
>>>> >> Therefore, it is safer/viable to create a proxyable wrapper object
>>>> which
>>>> >> implements Principal only and delegetas calls (that's what Weld
>>>> does).
>>>> >>
>>>> >> Otherwise I agree it could be nice to ahve a way to cast the object
>>>> as
>>>> >> the pure Principal interface doesn't help much.
>>>> >>
>>>> >> Matej
>>>> >>
>>>> >> ----- Original Message -----
>>>> >> > From: "John Ament" <[hidden email]>
>>>> >> > To: "cdi-dev" <[hidden email]>
>>>> >> > Sent: Wednesday, April 26, 2017 3:54:57 PM
>>>> >> > Subject: [cdi-dev] Types of Principal object
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > Hey guys
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > I raised a bug against the Weld guys, but think its worth an EG
>>>> >> discussion.
>>>> >> > When a Principal object is injected, the only type it has is
>>>> Principal.
>>>> >> It
>>>> >> > does not retain the actual type used at runtime. This threw me off
>>>> on
>>>> >> some
>>>> >> > Keycloak integration I'm working on (in $dayjob). So I was
>>>> wondering, is
>>>> >> > this expected from our POV or should it retain the types of the
>>>> actual
>>>> >> > runtime instance?
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > John
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > NOTICE: This e-mail message and any attachments may contain
>>>> >> confidential,
>>>> >> > proprietary, and/or privileged information which should be treated
>>>> >> > accordingly. If you are not the intended recipient, please notify
>>>> the
>>>> >> sender
>>>> >> > immediately by return e-mail, delete this message, and destroy all
>>>> >> physical
>>>> >> > and electronic copies. Thank you.
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > cdi-dev mailing list
>>>> >> > [hidden email]
>>>> >> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> >> >
>>>> >> > Note that for all code provided on this list, the provider
>>>> licenses the
>>>> >> code
>>>> >> > under the Apache License, Version 2
>>>> >> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>> ideas
>>>> >> > provided on this list, the provider waives all patent and other
>>>> >> intellectual
>>>> >> > property rights inherent in such information.
>>>> >>
>>>> >>
>>>> >> ------------------------------
>>>> >>
>>>> >> Message: 4
>>>> >> Date: Wed, 26 Apr 2017 17:11:11 +0200
>>>> >> From: arjan tijms <[hidden email]>
>>>> >> Subject: Re: [cdi-dev] Types of Principal object
>>>> >> To: John Ament <[hidden email]>
>>>> >> Cc: cdi-dev <[hidden email]>
>>>> >> Message-ID:
>>>> >>         <CAE=-AhA0PiXZpSKmy0XYoMxCFuyxjV3Wt=jjFzhC=G+LOc9TDA@mail.
>>>> >> gmail.com>
>>>> >> Content-Type: text/plain; charset="utf-8"
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> We discussed this very issue in the Security API EG as well. In the
>>>> >> Security API the actual type *MUST* be retained as per the spec
>>>> >> definition.
>>>> >>
>>>> >> The problem in CDI, at least in Weld, is that a proxy is injected.
>>>> This
>>>> >> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
>>>> >> where
>>>> >> AbstractEEBean does:
>>>> >>
>>>> >> public abstract class AbstractEEBean<T> extends
>>>> >> AbstractStaticallyDecorableBuiltInBean<T> {
>>>> >>
>>>> >>     private final T proxy;
>>>> >>
>>>> >>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
>>>> >> BeanManagerImpl beanManager) {
>>>> >>         super(beanManager, type);
>>>> >>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
>>>> >> type,
>>>> >> getTypes(), this).create(new EnterpriseTargetBeanInstance(type, new
>>>> >> CallableMethodHandler(callable)));
>>>> >>     }
>>>> >>     // ...
>>>> >> }
>>>> >>
>>>> >> I'm not even sure if it's possible to downcast the proxy to the
>>>> required
>>>> >> runtime type.
>>>> >>
>>>> >> Also note that the Principal can change during the request. The
>>>> simplest
>>>> >> case is when during an http request HttpServletRequest#logout is
>>>> called.
>>>> >>
>>>> >> Kind regards,
>>>> >> Arjan Tijms
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <
>>>> [hidden email]
>>>> >> >
>>>> >> wrote:
>>>> >>
>>>> >> > Hey guys
>>>> >> >
>>>> >> >
>>>> >> > I raised a bug against the Weld guys, but think its worth an EG
>>>> >> > discussion.  When a Principal object is injected, the only type it
>>>> has
>>>> >> is
>>>> >> > Principal.  It does not retain the actual type used at runtime.
>>>> This
>>>> >> threw
>>>> >> > me off on some Keycloak integration I'm working on (in $dayjob).
>>>> So I
>>>> >> was
>>>> >> > wondering, is this expected from our POV or should it retain the
>>>> types
>>>> >> of
>>>> >> > the actual runtime instance?
>>>> >> >
>>>> >> >
>>>> >> > John
>>>> >> >
>>>> >> > ------------------------------
>>>> >> > NOTICE: This e-mail message and any attachments may contain
>>>> >> confidential,
>>>> >> > proprietary, and/or privileged information which should be treated
>>>> >> > accordingly. If you are not the intended recipient, please notify
>>>> the
>>>> >> > sender immediately by return e-mail, delete this message, and
>>>> destroy
>>>> >> all
>>>> >> > physical and electronic copies. Thank you.
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > cdi-dev mailing list
>>>> >> > [hidden email]
>>>> >> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> >> >
>>>> >> > Note that for all code provided on this list, the provider
>>>> licenses the
>>>> >> > code under the Apache License, Version 2 (http://www.apache.org/
>>>> >> > licenses/LICENSE-2.0.html). For all other ideas provided on this
>>>> list,
>>>> >> > the provider waives all patent and other intellectual property
>>>> rights
>>>> >> > inherent in such information.
>>>> >> >
>>>> >> -------------- next part --------------
>>>> >> An HTML attachment was scrubbed...
>>>> >> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>>>> >> 6/206ff811/attachment.html
>>>> >>
>>>> >> ------------------------------
>>>> >>
>>>> >> _______________________________________________
>>>> >> cdi-dev mailing list
>>>> >> [hidden email]
>>>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> >>
>>>> >> Note that for all code provided on this list, the provider licenses
>>>> the
>>>> >> code under the Apache License, Version 2 (
>>>> http://www.apache.org/license
>>>> >> s/LICENSE-2.0.html).  For all other ideas provided on this list, the
>>>> >> provider waives all patent and other intellectual property rights
>>>> inherent
>>>> >> in such information.
>>>> >>
>>>> >> End of cdi-dev Digest, Vol 77, Issue 8
>>>> >> **************************************
>>>> >>
>>>> >
>>>> >
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/2017042
>>>> 6/ebea1962/attachment.html
>>>>
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
>>>> code under the Apache License, Version 2 (http://www.apache.org/license
>>>> s/LICENSE-2.0.html).  For all other ideas provided on this list, the
>>>> provider waives all patent and other intellectual property rights inherent
>>>> in such information.
>>>>
>>>> End of cdi-dev Digest, Vol 77, Issue 10
>>>> ***************************************
>>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (http://www.apache.org/license
>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>>> provider waives all patent and other intellectual property rights inherent
>>> in such information.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/b488a2eb/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html).  For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

End of cdi-dev Digest, Vol 77, Issue 17
***************************************


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
12
Loading...