Ответ 1

Похоже, что поддержка строки запроса была добавлена ​​к клиенту SockJS, см. https://github.com/sockjs/sockjs-client/issues/72.

Ответ 2

Текущая ситуация

ОБНОВЛЕНИЕ 2016-12-13: проблема, о которой идет речь ниже, теперь отмечена как фиксированная, поэтому теперь не требуется hack ниже Spring 4.3.5 или выше. См. https://github.com/spring-projects/spring-framework/blob/master/src/docs/asciidoc/web/web-websocket.adoc#token-based-authentication.

Предыдущая ситуация

В настоящее время (сентябрь 2016) это не поддерживается Spring за исключением параметра запроса, как ответил @rossen-stoyanchev, который много писал (все?) поддержки Spring WebSocket. Мне не нравится подход параметров запроса из-за потенциальной утечки HTTP-реферера и хранения токена в журналах сервера. Кроме того, если последствия безопасности не беспокоят вас, обратите внимание, что я нашел, что этот подход работает для истинных подключений WebSocket, но если вы используете SockJS с резервными копиями для других механизмов, метод determineUser никогда не вызывается для резервного копирования. См. Spring 4.x резервная аутентификация WebSocket SockJS на основе токенов.

Я создал проблему Spring, чтобы улучшить поддержку аутентификации на основе маркеров на основе токенов: https://jira.spring.io/browse/SPR-14690

Взлом

В то же время я нашел взломан, который хорошо работает при тестировании. Обход встроенного устройства Spring на уровне соединения Spring. Вместо этого установите токен аутентификации на уровне сообщения, отправив его в заголовки Stomp на стороне клиента (это прекрасно отражает то, что вы уже делаете с обычными вызовами HTTP XHR), например:

stompClient.connect({'X-Authorization': 'token'}, ...);
stompClient.subscribe(..., {'X-Authorization': 'token'});
stompClient.send("/wherever", {'X-Authorization': 'token'}, ...);

На стороне сервера получите токен из сообщения Stomp с помощью ChannelInterceptor

@Override
public void configureClientInboundChannel(ChannelRegistration registration) {
  registration.setInterceptors(new ChannelInterceptorAdapter() {
     Message<*> preSend(Message<*> message,  MessageChannel channel) {
      StompHeaderAccessor accessor = StompHeaderAccessor.wrap(message);
      List tokenList = accessor.getNativeHeader("X-Authorization");
      String token = null;
      if(tokenList == null || tokenList.size < 1) {
        return message;
      } else {
        token = tokenList.get(0);
        if(token == null) {
          return message;
        }
      }

      // validate and convert to a Principal based on your own requirements e.g.
      // authenticationManager.authenticate(JwtAuthentication(token))
      Principal yourAuth = [...];

      accessor.setUser(yourAuth);

      // not documented anywhere but necessary otherwise NPE in StompSubProtocolHandler!
      accessor.setLeaveMutable(true);
      return MessageBuilder.createMessage(message.payload, accessor.messageHeaders)
    }
  })

Это просто и получает от нас 85% пути, однако этот подход не поддерживает отправку сообщений конкретным пользователям. Это связано с тем, что Spring механизм, связанный с пользователями для сеансов, не влияет на результат ChannelInterceptor. Spring WebSocket предполагает, что аутентификация выполняется на транспортном уровне, а не на уровне сообщений, и, таким образом, игнорирует аутентификацию на уровне сообщений.

В любом случае взломать эту работу, чтобы создать наши экземпляры DefaultSimpUserRegistry и DefaultUserDestinationResolver, выставить их в среду, а затем использовать перехватчик, чтобы обновить их, как если бы он сам выполнял Spring. Другими словами, что-то вроде:

@Configuration
@EnableWebSocketMessageBroker
@Order(HIGHEST_PRECEDENCE + 50)
class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer() {
  private DefaultSimpUserRegistry userRegistry = new DefaultSimpUserRegistry();
  private DefaultUserDestinationResolver resolver = new DefaultUserDestinationResolver(userRegistry);

  @Bean
  @Primary
  public SimpUserRegistry userRegistry() {
    return userRegistry;
  }

  @Bean
  @Primary
  public UserDestinationResolver userDestinationResolver() {
    return resolver;
  }


  @Override
  public configureMessageBroker(MessageBrokerRegistry registry) {
    registry.enableSimpleBroker("/queue", "/topic");
  }

  @Override
  public registerStompEndpoints(StompEndpointRegistry registry) {
    registry
      .addEndpoint("/stomp")
      .withSockJS()
      .setWebSocketEnabled(false)
      .setSessionCookieNeeded(false);
  }

  @Override public configureClientInboundChannel(ChannelRegistration registration) {
    registration.setInterceptors(new ChannelInterceptorAdapter() {
       Message<*> preSend(Message<*> message,  MessageChannel channel) {
        StompHeaderAccessor accessor = StompHeaderAccessor.wrap(message);

        List tokenList = accessor.getNativeHeader("X-Authorization");
        accessor.removeNativeHeader("X-Authorization");

        String token = null;
        if(tokenList != null && tokenList.size > 0) {
          token = tokenList.get(0);
        }

        // validate and convert to a Principal based on your own requirements e.g.
        // authenticationManager.authenticate(JwtAuthentication(token))
        Principal yourAuth = token == null ? null : [...];

        if (accessor.messageType == SimpMessageType.CONNECT) {
          userRegistry.onApplicationEvent(SessionConnectedEvent(this, message, yourAuth));
        } else if (accessor.messageType == SimpMessageType.SUBSCRIBE) {
          userRegistry.onApplicationEvent(SessionSubscribeEvent(this, message, yourAuth));
        } else if (accessor.messageType == SimpMessageType.UNSUBSCRIBE) {
          userRegistry.onApplicationEvent(SessionUnsubscribeEvent(this, message, yourAuth));
        } else if (accessor.messageType == SimpMessageType.DISCONNECT) {
          userRegistry.onApplicationEvent(SessionDisconnectEvent(this, message, accessor.sessionId, CloseStatus.NORMAL));
        }

        accessor.setUser(yourAuth);

        // not documented anywhere but necessary otherwise NPE in StompSubProtocolHandler!
        accessor.setLeaveMutable(true);
        return MessageBuilder.createMessage(message.payload, accessor.messageHeaders);
      }
    })
  }
}

Теперь Spring полностью осведомлен об аутентификации, то есть он вводит Principal в любые требуемые ему методы контроллера, предоставляет его в контексте для Spring Security 4.x и связывает пользователя с WebSocket сеанс для отправки сообщений определенным пользователям/сеансам.

Spring Служба безопасности

Наконец, если вы используете поддержку Spring Security 4.x Messaging, убедитесь, что @Order вашего AbstractWebSocketMessageBrokerConfigurer имеет более высокое значение, чем Spring Безопасность AbstractSecurityWebSocketMessageBrokerConfigurer (Ordered.HIGHEST_PRECEDENCE + 50 будет работать, как показано выше). Таким образом, ваш перехватчик устанавливает Principal до Spring Безопасность выполняет свою проверку и устанавливает контекст безопасности.

Ответ 3

С последним SockJS 1.0.3 вы можете передавать параметры запроса как часть URL-адреса соединения. Таким образом, вы можете отправить токен JWT для авторизации сеанса.

  var socket = new SockJS('http://localhost/ws?token=AAA');
  var stompClient = Stomp.over(socket);
  stompClient.connect({}, function(frame) {
      stompClient.subscribe('/topic/echo', function(data) {
        // topic handler
      });
    }
  }, function(err) {
    // connection error
  });

Теперь все запросы, связанные с websocket, будут иметь параметр "? токен = AAA"

http://localhost/ws/info?token=AAA&t=1446482506843

http://localhost/ws/515/z45wjz24/websocket?token=AAA

Затем с помощью Spring вы можете настроить фильтр, который идентифицирует сеанс, используя предоставленный токен.