[cdi-dev] Types of Principal object

Romain Manni-Bucau rmannibucau at gmail.com
Wed Apr 26 11:41:08 EDT 2017


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 <arjan.tijms at gmail.com>:

> 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 <john.ament at spartasystems.com>
> 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
>> cdi-dev at lists.jboss.org
>> 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
> cdi-dev at lists.jboss.org
> 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.html 


More information about the cdi-dev mailing list