Results 1 to 5 of 5
  1. #1

    Question Implementing signup and login purely in LS

    Hi,

    We're developing a new LS client that would need to handle users signup and login. In the docs there's only one small part describing how to do this when legacy web server is used also (by authenticating on the web server actually).

    1. SIGNUP:
    We need to have a signup form, which when submitted would use LS sendMessage() to create user. We're implementing our own Metadata Adapter in Java (using ARI) and it's quite clear what to do on that side.

    The question is how should client (js for now) behave in this scenario. Client should be able to use other services only if he's correctly logged in, which should also happen immediately after a successful signup.

    First we'd open a connection to LS without any user/pass, call sendMessage() with submitted user signup details (user & pass at least), and if the server doesn't reply with exception (decided in our MetadataAdapter based on validity of signup details) client considers this as successful signup. Then what? Should client close this connection just to open new one with the newly approved user & pass? Is there a way to login using the currently open connection that was used for signup anyway?

    2.LOGIN:
    It seems pretty straightforward to set user & pass on connectionDetails, and it works just fine, but we're worried about constantly keeping the password available in the client upon setting it. Is there a better way of doing this, i.e. submitting password only once and forgetting it?

    There is one confusing sentence in the docs of connectionDetails property of LightstreamerClient: "Properties of this bean can be overwritten by values received from a Lightstreamer Server". Does this mean that server can override some of these properties automatically, without client actually calling setUser(), setPassword(), etc.? If so, how can this be done?

    Tnx,
    Dejan

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    If your client needs to open a session before authenticating, hence your Metadata Adapter can accept a session with no authentication and then authenticate the user via a sendMessage, this is fine for the Server. The Metadata Adapter has the full control of the situation and closing the session and reopening it with the correct credentials makes no difference from the Server point of view.
    Obviously, as long as the user is temporarily not authenticated, your Metadata Adapter should carefully manage the authorization of client requests. The only request it cannot refuse is that of opening the session.

    Once the credentials are established, supplying them to the client library is still useful, to take advantage of the automatic recovery from disconnections. If you think this may be a security issue, you might lean on temporary tokens or similar. We can expand on how the Adapter could communicate a token back to the client.
    On the other hand, we must clarify that when we say "Properties of this bean can be overwritten by values received from a Lightstreamer Server" we don't refer to the user credentials.

  3. #3
    Right, I was hoping that an already open connection could be "upgraded" with credentials, so that client wouldn't have to close it and open a new one. But ok, if that's the only way, we'll go with it.

    Regarding the temporary token, could you please elaborate on that? Any scenario that we could think of seems rather complex, involving at least one more token generated on client side (to subscribe secretly to an item where server would send back its token).

    BR,
    Dejan

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    Hi Dejan, you don't need to protect in some way the client request for the token, because, after your Metadata Adapter authenticates the client (even via sendMessage) it can treat any request on the session in a different way than before.
    What counts it that the request belongs to that session.

    So, for instance, if you use an item to carry the token, any subscription to that item can be refused before the authentication takes place and accepted after.
    Note that you also don't need to play with the item name, because a generic name can be decorated and turned into a session-specific item by the Metadata Adapter in getItems(); then the Data Adapter will recognize the session-specific item and feed it appropriately.

    In order to get a result as a consequence of a sendMessage call, an alternative way is shown in this thread (as "solution 2").

  5. #5
    Hi Dario,

    Decorating the item with sessionId was the missing piece of the puzzle. Tnx for the help.

    BR,
    Dejan

 

 

Similar Threads

  1. Implementing RTD Server Issue
    By programmer in forum Client APIs
    Replies: 3
    Last Post: January 14th, 2015, 05:52 PM
  2. Light streamer for Login user
    By rvkvino in forum General
    Replies: 3
    Last Post: September 25th, 2013, 10:20 AM
  3. User Authentication - Login
    By mluecke in forum Client APIs
    Replies: 1
    Last Post: August 2nd, 2012, 04:01 PM
  4. Light streamer for Login user
    By in forum General
    Replies: 0
    Last Post: January 1st, 1970, 01:00 AM

Tags for this Thread

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 12:14 AM.