You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Aki Yoshida (JIRA)" <ji...@apache.org> on 2014/04/17 17:49:16 UTC

[jira] [Comment Edited] (CXF-5698) Use the service root path instead of the initial request path to restrict websocket service access

    [ https://issues.apache.org/jira/browse/CXF-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973061#comment-13973061 ] 

Aki Yoshida edited comment on CXF-5698 at 4/17/14 3:48 PM:
-----------------------------------------------------------

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 deployed endpoint path "/websocket" but that path followed by the annotated path name of the service class) 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


was (Author: ay):
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)