Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15
  1. #11
    Member
    Join Date
    Jan 2007
    Location
    SomeCity
    Posts
    13
    That sounds good on paper... If you could just convince our IT department to allow us to do that...

    I was afraid that this was going to be the case.
    Thanks for the help!

  2. #12
    Member
    Join Date
    Sep 2007
    Location
    Chicago
    Posts
    20
    Alessandro,

    The authentication scheme you mentioned - "LS uses session_id based authentication'.

    Does this mean LS verifies the session_id from the browser with the web server? - how reliable is this over https? Can we depend on this for a production level app? Trying to understand how this works.

    If this is not recommended, do you recommend us implementing 'notifyUser()' in the MD adapter?

    Thanks,
    Kal

  3. #13
    Administrator
    Join Date
    Jul 2006
    Location
    Milan, Italy
    Posts
    517
    Kal,

    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.
    Attached Thumbnails Attached Thumbnails AuthorizationSequence.pdf  

  4. #14
    Member
    Join Date
    Sep 2007
    Location
    Chicago
    Posts
    20
    Perfect. I implemented it through the MD adapter and works great!

    Is there a way to log from the adapter? It will be great to log the user sessions through 'notifyUser'. I can add a logger but not sure where it will write the logs to? (Lightstreamer.log?)

  5. #15
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    I'm not sure I understand your logging needs. If you need to log each new session and the related user, then you can do it only in "notifyNewSession", as "notifyUser" is called before session creation.
    Admittedly, the Server log lacks this item; while each session name is logged by the Server at session creation (even in the default logging configuration), the related user name is not logged and can only be inferred by nearby log lines.

    As far as we know, log4j support is a singleton and (as the Adapter is loaded by the Server in the Server's own ClassLoader) all logging configuration in "lightstreamer_log_conf.xml" is available to Adapter code. You can log on the Server loggers; in this case, your log will share the appenders of the Server log (the console and Lightstreamer.log).
    Otherwise (and preferably) you can add and configure your own loggers/categories and appenders; if you inherit from "LightstreamerLogger", you can still share the appenders of the Server log. You can extend "lightstreamer_log_conf.xml" or even load your own configuration file, which will be merged with the Server one. In the latter case, in order to avoid conflicts, just leave the "root" element configuration empty.

    Dario

 

 

Similar Threads

  1. Replies: 1
    Last Post: July 10th, 2012, 07:06 PM
  2. Replies: 7
    Last Post: June 7th, 2010, 10:38 AM
  3. Replies: 3
    Last Post: February 19th, 2010, 12:14 AM
  4. Replies: 1
    Last Post: September 18th, 2009, 10:13 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 09:36 AM.