[cdi-dev] 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 <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:14 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> 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 <rmannibucau at gmail.com
> > 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 <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 <john.ament at spartasystems.com>:
>>
>>> 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/479fcb38/attachment.html