Return-Path: X-Original-To: apmail-cxf-issues-archive@www.apache.org Delivered-To: apmail-cxf-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 62EA310E99 for ; Thu, 17 Apr 2014 15:21:38 +0000 (UTC) Received: (qmail 30482 invoked by uid 500); 17 Apr 2014 15:21:28 -0000 Delivered-To: apmail-cxf-issues-archive@cxf.apache.org Received: (qmail 30412 invoked by uid 500); 17 Apr 2014 15:21:26 -0000 Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list issues@cxf.apache.org Received: (qmail 30345 invoked by uid 99); 17 Apr 2014 15:21:24 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Apr 2014 15:21:24 +0000 Date: Thu, 17 Apr 2014 15:21:24 +0000 (UTC) From: "Aki Yoshida (JIRA)" To: issues@cxf.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CXF-5698) Use the service root path instead of the initial request path to restrict websocket service access MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CXF-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973061#comment-13973061 ] Aki Yoshida commented on CXF-5698: ---------------------------------- Hi Sergey, The original intention was, let's say, using the example in systests/jaxrs, to start with "/websocket/web/bookstore/books/123" to open a socket connection and use this socket connection to call another operation "/websocket/web/bookstore/booknames". Currently, this is failing. I stumbled on this problem, when I wrote the client part (i.e., conduit) that used the operation URL path in the initial socket open request. But it turned out, it seems not so simple to determine the service root path "/websocket/web/bookstore" (not the endpoint path) without checking the deployed jaxrs resource. So I will drop this patch/change and instead, assume the client to be smart enough (e.g., it has the resource description) and knows the service root path "/websocket/web/bookstore" so that it can issue the correct socket open request. regards, aki > Use the service root path instead of the initial request path to restrict websocket service access > -------------------------------------------------------------------------------------------------- > > Key: CXF-5698 > URL: https://issues.apache.org/jira/browse/CXF-5698 > Project: CXF > Issue Type: Improvement > Components: Transports > Reporter: Aki Yoshida > Assignee: Aki Yoshida > Fix For: 3.0.0 > > > Currently, the URL path used to initiate the websocket connection is used to allow or restrict the subsequent operations received over the websocket. > This is not convenient as the caller must know the service root path to be able to invoke all the operations supported by the service. A more convenient approach would be to use the service root path as the filter so that the subsequent requests to one of its operations can be processed even if the initial connection request uses one of these sub resource paths. -- This message was sent by Atlassian JIRA (v6.2#6252)