STOMP and SockJS support and security not obvious from the starter

General
1

Hi,

The newest Vaadin starter and its login form and security setup, which is a nice addition; However, adding STOMP and SockJS to the starter with a broker and controller has security configuration implications. The Spring docs for WebSocket security do not mesh well with the setup Vaadin is using. Before the socket can be used the user needs to auth. I was trying to use it in this way without auth in the starter.

Due to the popularity of STOMP and SockJS it was the first thing I turned to. The docs currently are focused on the reactive style for push, which is great.

Any help would be appreciated.

2

I have no direct assistance but I’m a bit curious about the use case for STOMP in a Vaadin application. Will you use it with a Vaadin UI, some supplementary UI built with some other technology, or for 3rd party clients?

3

Thanks for asking. It seemed like the path of least resistance for an existing react socket application. There are so many pointers when looking to using STOMP out there and so little that suggest otherwise. So, a naive person, such as myself could look at the Spring Security docs and see this. And it just makes things worse.

@Configuration
@EnableWebSocketSecurity
public class WebSocketSecurityConfig {
    @Bean
    AuthorizationManager<Message<?>> messageAuthorizationManager(MessageMatcherDelegatingAuthorizationManager.Builder messages) {
        messages.anyMessage().permitAll();
        return messages.build();
    }
}

I felt like the docs that are provided for Vaadin, discuss push, but for a React dev (familiar with Java), they don’t click. It implies something that seems more complicated than just a traditional WebSocket server. The starter also could use a push example to, well, push the naive new user such as me the right direction. Making things worse, but better, the starter added a new login that is flow on a hilla starter. This made the WebSocket securtity thing much harder to navigate.

I’ve since resigned myself to using the documented server-push for hilla and had much better success, especially since I can use @AnonymousAllowed and @BrowserCallable.

I think it would be great to have both options. Obviously one could be discouraged in favor of the reactive one. There likely would be others who have an existing STOMP app and want to migrate.

2 Likes
4

Good that you found a working solutions with the built-in @BrowserCallable. That will in general always be the “best” option in combination with a UI that is also otherwise built using Hilla thanks to the tight integration with the rest of Hilla.

From that point of view, I’m mainly wondering if there’s something we could adjust e.g. in the documentation to increase the chances that someone with your background would consider it as a good option right away rather than only as a last resort after struggling with other options?

5

Thanks for asking. I think it is the language and locations of the examples. While there is a server push doc area, Hilla is kinda buried. There are relevant docs in Guides->Reactive Endpoints doesn’t scream server push or SSE. There is Building Apps->Deep Dives->Application Layer and Presentation Layer … Hilla. It is harder to follow it and see what you need to do and it turns out it is relatively much simpler than the sum of that whole.

It is like each doc is not aware of the other and is trying to get some point across, but not in a cohesive way. They have important points, but the cognitive load on making sense of it all is high until you have some knowledge.

The last thing is new terminology FLux, Mono, Sink, and so on. It may not be new, but it really is not explained. It is hand waived with the link to Into to Reactive programming. Obviously you don’t want to duplicate what they say, but that intro is heavy, academic in nature. So, some simple language to each, like the first sentence in the reactor Core features, like it saying Flux is 0 to N asynchronous sequence.

Most users will need a Flux endpoint and a Sink and that really doesn’t come through well in the docs.

A complete good example. They are out there, but a hunt to find.

Sadly the Vaadin YouTube videos are outdated. While good and appreciated, they are a chore to align with the latest. I also think they lean to heavily on Flow. I understand it may be volunteer and I’m certainly not doing it, so it is a wish list. Some good Hilla content that really understands the latest React trends and how Vaadin is a fantastic backend platform, oh that would be so good.

This all is from a Reat Hilla perspective.

Again thanks for asking.

1 Like