You miss the point that JAX-RS does not mandate that CDI must be used
on Java SE. So the interceptor will never get called.
Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
> On Tue, Mar 1, 2016 at 11:12 PM, <markus_at_headcrashing.eu> wrote:
>
>> The JAX-RS specification says that JAX-RS can be used not only within Java
>> EE but also as a standalone technology ontop of Java SE. To make a JAX-RS
>> application work correctly in both environments (hence: without JSR 375
>> beneath) the JAX-RS specification either must declare that JSR 375 is to be
>> bundled with JAX-RS on Java SE, or it must define a different way to
>> declare security with in turn enables JSR 375 on Java EE but may use any
>> other technology on Java SE.
>
>
> JAX-RS doesn't have to know about an Interceptor based @RolesAllowed, does
> it?
>
> Such an interceptor can be applied to every method to which Interceptors
> can be applied and it does what it does then. No need for JAX-RS to be
> aware of what it exactly does, so no need for JAX-RS to define a different
> way for when JAX-RS runs on top of Java SE.
>
> It's not that different from using say the @Transactional interceptor.
> Anyone can apply that to a method, and if that method is applicable for
> interception a transaction it will be transactional. But JSF, MVC, JAX-RS
> and what have you do not all need to go duplicate JTA or provide JTA
> delegation mechanisms, do they? They only need to use CDI beans, which
> automatically provides Interception, and then the actual interceptors
> people put on their methods is not the concern of the spec that just uses
> CDI and/or Interceptors.
>
>
>
>
>>
>>
>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>
>> If it's an Interceptor spec interceptor, will it not run regardless of what
>>> the JAX-RS spec otherwise says about security?
>>>
>>> On Tue, Mar 1, 2016 at 10:31 PM, <markus_at_headcrashing.eu> wrote:
>>>
>>> To clarify my proposal, I actually don't care about *which* annotation is
>>>> getting used, as long as JAX-RS 2.1 specifies one common solution for ALL
>>>> implementations. Certainly my vote would be for "enable @RolesAllowed by
>>>> default" as it is what currently everone simply would expect to work out
>>>> of
>>>> the box.
>>>>
>>>> Zitat von arjan tijms <arjan.tijms_at_gmail.com>:
>>>>
>>>>
>>>> What do you think?
>>>>
>>>>>
>>>>>>
>>>>> As we're streamlining security for the entire platform via JSR 375, I
>>>>> would
>>>>> not be a fan of having another JAX-RS (or any spec for that matter)
>>>>> specific annotation or other artefact to deal with security.
>>>>>
>>>>> One of the plans for JSR 375 is to have an Interceptor spec/CDI based
>>>>> @RolesAllowed equivalent, which may be more consistent, especially if
>>>>> JAX-RS also further aligns with CDI.
>>>>>
>>>>> For the existing common annotations version of @RolesAllowed I would
>>>>> definitely go for "Enable it by default.". These things should Just
>>>>> Work,
>>>>> and not require any "activation" really (some EJB containers had the
>>>>> same
>>>>> problem, a need to activate @RolesAllowed, really inconvenient and
>>>>> hurting
>>>>> portability of apps).
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 1, 2016 at 6:28 PM, <markus_at_headcrashing.eu> wrote:
>>>>>
>>>>> Experts,
>>>>>
>>>>>>
>>>>>> I hope you're in the mood for another small spec clarification in the
>>>>>> hope
>>>>>> to further align Jersey, WebSphere, CXF and RestEasy. :-)
>>>>>>
>>>>>> The current Jersey manual says that it will respect role-based security
>>>>>> annotations (@PermitAll, @DenyAll, @RolesAllowd; according to JSR 250
>>>>>> "Common Annotations for the Java Platform") as soon as a
>>>>>> Jersey-specific
>>>>>> filter is EXPLICITLY enabled by means of JAX-RS feature config API. If
>>>>>> I
>>>>>> understood the WebSphere manual correctly, I respects these annotations
>>>>>> BY
>>>>>> DEFAULT. According chapter 36 of its manual, it seems as if RESTeasy
>>>>>> wants
>>>>>> EXPLICIT enabling by Servlet web.xml. CXF on the other hand apparantly
>>>>>> wants the deployer to enable an interceptor EXPLICITLY. So all those
>>>>>> JAX-RS
>>>>>> products process these annotations, but each has a different way to
>>>>>> enable
>>>>>> it. Looking through the eyes of an ISV, this is real pain-in-the-*
>>>>>> since
>>>>>> security is a must-have in all non-trivial products and nobody wants to
>>>>>> provide four different configs for the same off-the-shelf app.
>>>>>>
>>>>>> I'd like to suggest that the spec 2.1 defines ONE COMMON way which
>>>>>> enables
>>>>>> security on ALL JAX-RS products.
>>>>>>
>>>>>> I have two proposals:
>>>>>>
>>>>>> (a) Enable it by default. It should not do any real harm regarding
>>>>>> backwards compatibility. This way, nobody has to worry about security
>>>>>> besides adding above role annotations.
>>>>>>
>>>>>> (b) Enable it explicitly by adding @Secured on the Application class. I
>>>>>> think this is ugly as the existence of above annotations already imply
>>>>>> that
>>>>>> security is wanted.
>>>>>>
>>>>>> As all products already support the functionality, we just need to
>>>>>> agree
>>>>>> upon a SINGLE way to enable it. I think people simply expect this in
>>>>>> 2.1.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> -Markus
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>