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.