Closed chrosim closed 2 years ago
The original reason for why we didn't use a custom URL like /VAADIN/beacon
when fixing https://github.com/vaadin/collaboration-engine/issues/41 was because that would have required us to add an exception for that URL in the Spring Security integration (CSRF protection in particular if I remember correctly) that is defined through code in Flow. We wouldn't want to have a dependency from Flow to Collaboration Engine (even an implicit one with just a hardcoded string) so we did instead find a URL pattern that the existing configuration happened to be compatible with.
One potential approach that would help deal with this kind of situation without hardcoding CE specifics in Flow would be to make the beacon URL configurable while still keeping the default value as it is today. In that way, you could define a custom beacon URL that CE would use and then add exceptions for it in the Keycloak configuration.
Another potential thing that you can look into is whether spring-boot-keycloak-adapter
can be configured also based on request parameters rather than only based on the request path. If this is possible, then you could look for the value beacon
in the v-r
parameter for requests to the application root.
We already tried to configure with request parameters, sadly it is not possible. But the possibility to configure the beacon URL would help.
Starting from Collaboration Engine 5.0 this will be configurable (5.0.0.beta1
is expected to be release later this week).
@chrosim we've just released Collaboration Engine 5.0.0.beta1
which contains a new method to set a custom beacon path: CollaborationEngineConfiguration::setBeaconPath
. Let us know if this feature helps you on your use case!
@heruan i finally managed to test it. Seems to be working for us. What i found so far is that the beacon url seems not to be used in development mode. And the system environment variable 'vaadin.ce.beaconPath' seems to be ignored. The only way i got it working was using jvm param -Dvaadin.ce.beaconPath or configuring it through the CE-Configuration directly.
We are using the spring-boot-keycloak-adapter to secure our app. Therefor each view at least needs a user to be logged in, otherwise the user gets redirected to the keycloak login page. The adapter provides the possibility to open/close specified request paths to roles. For Vaadin internal requests we have setup some whitelistings e.g:
Since BeaconHandler was changed from
/beacon/
to root path we've lost the possibility to whitelist BeaconHandler-requests which leads to a Race-Condition related login problem after a user logs out from a view using CE, for example CE-AvatarGroup or CE-Binder.