[cdi-dev] Types of Principal object

[Romain Manni-Bucau]

2017-04-26 18:07 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> Hi,
>
> On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <rmannibucau at gmail.com
> > 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 <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/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-0001.html