According to the documentation, the iframe fallback is useful for transports with no native cross-domain communication. See : https://github.com/spring-projects/spring-framework/blob/58e40d1aa2c23f6d9c41d4289f5b5debc10868f6/spring-websocket/src/main/java/org/springframework/web/socket/sockjs/support/AbstractSockJsService.java#L146

But when configuring my app for allowing a specific origin, and when my client request the Iframe, this bloc of code prevent me from getting it : https://github.com/spring-projects/spring-framework/blob/58e40d1aa2c23f6d9c41d4289f5b5debc10868f6/spring-websocket/src/main/java/org/springframework/web/socket/sockjs/support/AbstractSockJsService.java#L407

This bloc of code seems to say I could bypass it by setting "*" in allowOrigins. But it then conflicts with the "Access-Control-Allow-Credentials" set to true, which is forbidden for the "*" regex. https://docs.spring.io/spring-framework/docs/5.3.2/reference/html/web.html#websocket-fallback-sockjs-overview)

I have the feeling there is a contradiction here. For some transport, I need and iframe when I want to do cross-domain communication. But the very same process of providing an iframe is restricted if I want to access it cross-domain.

Is this code outdated and need an update? Or am I missing a point? If option one, I can work on the PR.

Comment From: rstoyanchev

In 5.3 we no longer allow allowedOrigins to be "*" in combination with "Allow-Credentials". Instead you can use the allowedOriginPatterns property which also allows more flexible patterns.

I can see that the Javadoc for WebSocketHandlerRegistration#setAllowedOrigins doesn't explicitly mention this the way that CorsConfiguration#setAllowedOrigins does. I'll update that.