mthizo247 / spring-cloud-netflix-zuul-websocket Goto Github PK

the example on README.md shows a configuration related to STOMP over web socket.

How to configure zuul to proxify a pure web socket (without STOMP) ?

For example, the web socket would be exposed as:

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {

    @Bean
    public ServletServerContainerFactoryBean createWebSocketContainer() {
        ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean();
        return container;
    }

    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(new TextWebSocketHandler() {

            @Override
            public void handleTextMessage(WebSocketSession session, TextMessage serializedMessage) throws IOException {
                session.sendMessage(new TextMessage("OK for " + serializedMessage.getPayload()));

            }
        }, "/ws/mywebsocket").setAllowedOrigins("*");
    }

}

Cannot be routed to the service after redirecting using springmvc "is not a valid HTTP URL"

Please help answer it. Thank you very much.

the demo just directly proxy the apps,not via zookeeper or erueka ,so i change the demo to zookeeper ,the demo will not work!!!

`***************************
APPLICATION FAILED TO START

Description:

Parameter 0 of method stompClient in com.github.mthizo247.cloud.netflix.zuul.web.socket.ZuulWebSocketConfiguration required a single bean, but 2 were found:
- brokerMessageConverter: defined by method 'brokerMessageConverter' in org.springframework.web.socket.config.annotation.DelegatingWebSocketMessageBrokerConfiguration
- datatypeChannelMessageConverter: defined in null

Action:

Consider marking one of the beans as @primary, updating the consumer to accept multiple beans, or using @qualifier to identify the bean that should be consumed
`

Fail to start by dependency injection
the pom is

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId> <scope>provided</scope> </dependency> <dependency> <groupId>com.github.mthizo247</groupId> <artifactId>spring-cloud-netflix-zuul-websocket</artifactId> <version>1.0.0-RELEASE</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-oauth2</artifactId> </dependency> </dependencies>

my Application.java is

`@EnableAutoConfiguration
@EnableDiscoveryClient
//@EnableZuulProxy
@EnableZuulWebSocket
@EnableWebSocketMessageBroker
@componentscan
public class Application {

public static void main(String[] args) {
	SpringApplication.run(Application.class, args);
}

@Bean
public PreFilter preFilter() {
    return new PreFilter();
}

}`

We have tried to use this library with OAuth2 authentication. The OAuth2BearerPrincipalHeadersCallback puts the token correctly to the header, but when we try to use it on a Tomcat server it fails because the ByteBuffer has fixed size and the content is too long. See:
https://stackoverflow.com/questions/50352739/tomcat-websocket-bufferoverflowexception

Did you try it with Tomcat server or something else? Have you faced with similar issue? Is there any way to decrease the size of the token or use cookies instead?

One subscribe to @SubscribeMapping should return one message, but when subscribe multiple times, excessive messages are returned:

Client:

stompClient.subscribe('/app/msg', function(msg) {
            console.log("subscribe1 callback");
        });
        stompClient.subscribe('/app/msg', function(msg) {
            console.log("subscribe2 callback");
        });

Server:

@SubscribeMapping("/msg")
	public Greeting msg() {
		return new Greeting("Hello, World!");
	}

Expected:
Two messages with content Hello, World! returned.

But excessive messages are returned.

Logs:

Web Socket Opened...
18:10:24.104 stomp.min.js:8 >>> CONNECT
accept-version:1.1,1.0
heart-beat:10000,10000


18:10:24.173 stomp.min.js:8 <<< CONNECTED
version:1.1
heart-beat:0,0


18:10:24.174 stomp.min.js:8 connected to server undefined
18:10:24.181 app.js?_=dsd:24 Connected: CONNECTED
heart-beat:0,0
version:1.1


18:10:24.182 stomp.min.js:8 >>> SUBSCRIBE
id:sub-0
destination:/app/msg


18:10:24.182 stomp.min.js:8 >>> SUBSCRIBE
id:sub-1
destination:/app/msg


18:10:25.271 stomp.min.js:8 <<< MESSAGE
destination:/app/msg
message-id:559f29a724bd48b794f270b71a18aa71-1
content-type:application/json;charset=UTF-8
subscription:sub-0
content-length:27

{"content":"Hello, World!"}
18:10:25.272 app.js?_=dsd:34 subscribe1 callback
18:10:25.273 stomp.min.js:8 <<< MESSAGE
destination:/app/msg
message-id:559f29a724bd48b794f270b71a18aa71-1
content-type:application/json;charset=UTF-8
subscription:sub-1
content-length:27

{"content":"Hello, World!"}
18:10:25.273 app.js?_=dsd:37 subscribe2 callback
18:10:25.277 stomp.min.js:8 <<< MESSAGE
destination:/app/msg
message-id:559f29a724bd48b794f270b71a18aa71-0
content-type:application/json;charset=UTF-8
subscription:sub-0
content-length:27

{"content":"Hello, World!"}
18:10:25.277 app.js?_=dsd:34 subscribe1 callback
18:10:25.278 stomp.min.js:8 <<< MESSAGE
destination:/app/msg
message-id:559f29a724bd48b794f270b71a18aa71-0
content-type:application/json;charset=UTF-8
subscription:sub-1
content-length:27

{"content":"Hello, World!"}
18:10:25.279 app.js?_=dsd:37 subscribe2 callback

Thanks!

Currently it's not possible to utilize any custom headers sent via STOMP connect command (for example custom authentication data). This is due to the fact that connectToProxiedTarget doesn't accept WebSocketMessageAccessor as other command methods do.

If the websocket is exposed on a different path than the path request, the websocket connection will fail.
In the following case, the websocket is exposed on http://localhost:10008/my-websocket
And there is a zuul proxy with the following config:

zuul:
  routes:
    websocket:
      path: /ws/**
      url: http://localhost:10008
      customSensitiveHeaders: true
  ws:
     brokerages:
       websocket:
         end-points: /mywebsocket
         brokers:  /topic
         destination-prefixes: /

When the client connects to websocket with the url http://proxy/ws/mywebsocket, the zuul proxy does not route the call to localhost:10008
If I change the route configuration to reflect the route path:

end-points: /ws/mywebsocket

Then the websocket connection fails again with the following message:
c.g.m.c.n.z.web.socket.ProxyWebSocketConnectionManager | Error connecting to web socket uri http://localhost:10008/ws/mywebsocket

There is a workaround to this problem, by setting both request path and websocket paths in the end-points parameter:

end-points: mywebsocket,ws/mywebsocket

Doing this, the previous message (Error connecting to web socket uri...) still appears, but the web socket connection succeeds. I guess that the endpoints are tried in order.

There should be a way to route web sockets calls, even if path differs betwen request path and host path.

In the following link, someone says this library is not really zuul websocket support, it's a standalone websocket proxy that happens to sit next to zuul. And I configured a zuul mandatory filter and found that the websocket connection did not go through the zuul filter.

My question is what's the implementation consideration of this library? Is it possible to make the websocket connection go through the zuul filter? To put it in another way, is it possible to support the websocket connection in zuul filters by using spring websocket compoment?

Thank you.

spring-cloud/spring-cloud-netflix#163

When I start multiple hello services, I try to send Greetings. The push information service is always the last one and does not support load balancing.

Hi,
I try to understand how to use this tool.
I'd like to try the example model but in application.yml I have the warning "unknown property zuul.ws"
There is something that I need to do to try it?

In my project, the front and back end separation is adopted, which is forwarded through nginx and zuul，then return error 400 . if only through nginx is ok.
the zuul properites is:
zuul:
host:
socket-timeout-millis: 30000
ignored-services: '*'
routes:
# 登录服务
auth_server:
serviceId: unified-login-center-server
path: /auth/**
custom-sensitive-headers: true
sensitiveHeaders: Cookie,Set-Cookie
# 权限控制中心
uacc:
serviceId: unified-authority-control-server-hlsc
path: /uacc/**
sensitiveHeaders: Cookie,Set-Cookie,Authorization
platform:
serviceId: hlsc-platform-server
path: /hlsc-platform/**
sensitiveHeaders: Cookie,Set-Cookie,Authorization
ws:
brokerages:
platform:
end-points: /webSocketServer
brokers: /topic
destination-prefixes: /app
server:
servlet:
context-path: /gwhlsc
and the websocket url is
var socket = new SockJS("http://192.168.5.66/gwhlsc/hlsc-platform/webSocketServer");

I have implemented security in notification microservice by using [Web sockets with Spring and Spring Security] (https://robertleggett.wordpress.com/2015/05/27/websockets-with-spring-spring-security/)

The microservice runs super fine before integrating with spring-cloud-netflix-zuul-websocket. But after that it stopped working.

I have observed it deeply and found that spring-cloud-netflix-zuul-websocket library is sending CONNECT request's response 'CONNECTED' back from gateway only and after that it sends the request to actual micro-service for authentication.

Expected behavior is to send it for authentication first then only allow it to be CONNECTED or DISCONNECT (based on result of auth).

Any help will be appreciated .

I'm using this to send messages to users that may have multiple tabs/windows open. I noticed in this case duplicate messages are sent from the proxy. I can also reproduce this with the demo, https://github.com/mthizo247/zuul-websocket-support-demo.

When using the demo, start the proxy and hello app. Open two tabs or windows going through the proxy, http://localhost:7078/, and click connect on both. Enter your name in the "What's your name?" input box, then click send. Observe in the console that two "MESSAGE" responses are received in both. If you have three tabs or windows open, then three "MESSAGE" responses are sent to each.

If you do the same thing going directly to the hello app, http://localhost:7079/, you don't get the duplicate messages.