Consider allowing overriding of the default EndpointAccessChecker bean

[vlukashov]

@campbellbartlett commented on Mon Dec 30 2019

Would it be possible to consider allowing custom AccessChecker beans to be defined so that a developer could implement their own?

This would be beneficial when using other authentication methods that aren't 0Auth2 or AnonymousAuth (in a project I'm working on, I'm using SocialLogin via auth0.com, which means there is no concept of username / password in the token I'm sending to the backend and the token is authenticated using other mechanisms before reaching the VaadinConnectAccessChecker).

I think it would be as easy as adding: @ConditionalOnMissingBean to the Bean definition for the EndpointAccessChecker in the EndpointControllerConfiguration.java class.

This way, if a developer wishes to override the default access check behavior they can do so by defining their own Bean that extends the EndpointAccessChecker.

---

@vlukashov commented on Mon Dec 30 2019

Hi @campbellbartlett! Thanks for the suggestion! I think it makes total sense.

Please note that Vaadin Connect features are being integrated into the core of Vaadin framework (with Vaadin 15 as the target release version). As we make these features a part of our core product, there is no plan to keep maintaining this repo separately.

Would it work for you if I move this issue to the https://github.com/vaadin/flow repo so that it gets implemented in Vaadin 15 instead? There is a team actively working on it now, and this feature can be added rather soon to one of the next Vaadin 15 alphas.

If this is news to you, you could check the quick start page for TypeScript views in Vaadin 15 to get some more info on this, and also to try it out.

---

@campbellbartlett commented on Mon Dec 30 2019

Thanks! I had no idea Connect was being integrated into Vaadin 15, I’ll check it out. Go ahead and move this issue to wherever it needs to be.

EDIT: updated VaadinConnect... class names to Endpoint..., as the classes were renamed

[eriklumme]

It can be overridden by creating your own bean marked with @Primary, but it needs documenting.

[Frettman]

It can be overridden by creating your own bean marked with @Primary, but it needs documenting.

This seems like a feasible workaround for now. But that still feels like we're messing with parts of the framework that we're not necessarily supposed to touch. As such, I'd also request to annotate the bean method with @ConditionalOnMissingBean. And additionally turn VaadinConnectAccessChecker into an interface. That makes it clear that this is a customizable gear in the framework, with or without documentation.

For a bit of context: I have an integration with Spring Security that allows me to secure (Java) views using an annotation that can e.g. make use of Spring Security expressions:

@SecuredRoute("hasRole('ADMIN')") @Route("admin")

So now I'm looking to provide the exact same possibilities for endpoints to keep access rules consistent.