Re: [Resteasy-users] Converting interceptor from RestEasy 2 to 3

[Savvas A. M. <sav...@gm...>]

​Hi Fausto,

It doesn't look like there is a more straightforward solution to this ​than
what you've some up with. What I'd have done however is make the
TokenValidatorInterceptor a "non-managed" class (in whatever DI framework
you are using) meaning a simple, plain class. Then I'd inject all its
required dependencies into the DynamicFeature (since it's @Provider) and
have that instantiate and register a TokenValidatorInterceptor. In that
sense (and in GRASP parlance) the latter would act as a "creator" of the
former.

HTF,
Savvas

On 1 February 2016 at 17:03, Fausto Santos <fst...@gm...> wrote:

> I'm converting an application from RestEasy 2 to 3. There is one
> authorization interceptor that implements PreProcessInterceptor and
> AcceptedByMethod interfaces. This interceptor is responsible for verifying
> an encrypted token in the request, and then authorizing or not the
> execution of a given method. There is also a @TokenValidationNotRequired
> annotation, to avoid the validation of the token on some methods, including
> the authentication method.
>
> So I changed the PreProcessInterceptor to a ContainerRequestFilter, and as
> the AcceptByMethod interface is deprecated I decided to use the Name
> Binding feature, then I would have to change the annotation to
> @TokenValidationRequired and put it in all methods that need authorization
> checking. This would result in a huge refactoring, and it's a bit insecure
> because other developers may forget to use the annotation. It's better to
> explicit annotate methods that doesn't need authorization checking, than
> doing the opposite.
>
> So I implemented a DynamicFeature that verifies methods that doesn't have
> the @TokenValidationNotRequired annotation and bind the
> TokenValidationInterceptor to them, like this:
>
> context.register(TokenValidatorInterceptor.class);
>
> The problem is that if I leave the interceptor annotated with @Provider,
> it becomes a global interceptor. If I remove it, the interceptor is
> correctly binded, but the autowiring on it's properties doesn't happen. I
> solved the problem by injecting the application context in the
> DynamicFeature and then getting the interceptor from the context, like this:
>
>
> context.register(applicationContext.getBean(TokenValidatorInterceptor.class));
>
> Is there an easier, or more correct, way of doing this? Something like a
> reverse name binding, that only binds the interceptor to methods that
> doesn't have the specific annotation?
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Resteasy-users mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>