Hi,
The "token" is application scoped not session scoped. I do agree that the
full url should be generated by the server and passed to the client. I will
look into it.
Cheers ,B
On Tue, Oct 4, 2016, 05:36 Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
> Hi
>
> Following a more exhaustive review of f:websockets, I have found some
> inconsistencies related to the way how a connection is specified.
>
>
>
> Please note there is no mention of jsf.push.init(...) in the
> javascript documentation, but the package jsf.push is there.
>
> Here is an example:
>
> <script type="text/javascript">
> jsf.push.init(8080,'clock?1e4ac202-2b21-434f-8431-de5d5e4d37fe',
> socketOpen,socketListener,socketClose,true);</script>
>
> If you use "jsf" javascript package, every method there should be specified
> without exceptions. I know this feature is a "work in progress" but I just
> wanted to notice this fact.
>
>
>
>
> Other thing to notice is there is a session token used to identify the
> connection. This is something related to state management, so I was
> expecting
> a method inside ResponseStateManager, in the same way there is a method
> there called:
>
> public String getCryptographicallyStrongTokenFromSession(FacesContext
> context)
>
> to handle protected views. Something like:
>
> public String
> getCryptographicallyStrongTokenForWebsocketSession(FacesContext context)
>
> It is only the token generation what we need here, not the websocket
> session handling.
>
>
>
> At last, there is a problem with passing params to assemble the url used
> for the connection in the client. It has been a long standing policy in
> JSF
> to generate urls on the server and pass them to the client. But in the
> javascript documentation a new variable was added called:
>
> jsf.contextpath
>
> with description "... The result of calling
> ExternalContext.getRequestContextPath(). ..."
>
> It looks like something recently added, so I guess it should be something
> related to jsf.push.init(...) script.
>
> The problem here is there is no way for the server to override this path,
> and in cases like portlets for example, it is necessary to provide a way
> to override this part properly. So the url used to connect must be built
> fully on the server and use the known ViewHandler - ExternalContext
> pattern. Additionally, embed this variable in the js file breaks any
> caching strategy. If the content is dynamic, embed it as an inline script,
> but in this case it is better to avoid that.
>
> regards,
>
> Leonardo Uribe
>
>