What I mentioned was indeed the nofifyUser() implementation. That's the only possible way to validate a sessionId.
For a more detailed explanation, I will cut&paste, below, a description from the General Concepts guide (see the attached PDF for the sequence diagram).
The figure focuses on the authorization process. It illustrates the typical best practice used for Web applications, when a Web/Application server is involved in the process. The actual authentication is usually handled by the legacy Web/Application server, irrespective of Lightstreamer. Some sort of session_id is sent back to the Client (through cookies, response payload or any other technique). When the Web Client creates the Lightstreamer session, instead of sending again the full credentials (usually involving a password) to Lightstreamer Server, it sends just the session_id (or the username and the session_id). The Metadata Adapter is passed this information and validates the session_id against the Web/Application Server that generated it (or a database or whatever back-end system).
The advantage of this practice is that the user’s password is never used outside the legacy system. Also, since the communication between the Client and Lightstreamer Server can leverage HTTPS, the session_id can be encrypted, so that it cannot be intercepted on the network.
This is just an example, because the Metadata Adapter is usually implemented in a custom way for each project, when integrating Lightstreamer into an existing or a new system.
Bookmarks