Hi Riad
@rsouissi, Wrote:
1) If I allow the server side to generate a client code which sets the user and the password, I would be exposing the password as plain text in the client HTML page, even if SSL is used. Which is a security issue.
What I tought maybe is the following:
- Apache authenticates user and creates a session cookie maintained by the client browser. Back-end saves the session in the DB and assigns to it the username the client used.
- Client uses the lightsteamer which create a new lightstreamer session, same as Apache. Lightstreamer meta adapter looks up the session from DB and resolves the username.
But it seems the session id create by lightstreamer has nothing to do with the browser HTTP session, right ?
Any other technique that can do a better job ?
Lightstreamaer Server does not check for session cookies in the HTTP requests it receives.
However, you can pass the session cookie content to setUserName (and ignore setPassword); the session cookie is already visible on the client side, so this should not affect security.
Then, as you remarked, the Metadata Adapter has to lookup the session cookie and find the associated "real" user in order to decide whether to allow or restrict the access.
This is the commonly used technique.
The session id created by Lightstreamer is indeed only for internal use.
@rsouissi, Wrote:
2) I am not sure I understand the use of notifyNewTables(). If I want to restrict a user into accessing only his items, I can rely on getItems(), right ?
Yes, the notifyNewTables() method has been made available only to allow a server-side check on the overall subscription activity within a session.
For example, it can be used to prevent the user from opening too many popup windows.
If a specific item cannot be subscribed to by a user, the client page logic and the getItems() method should disallow it.
@rsouissi, Wrote:
3) New question: If two lightstreamers must be used for loadbalancing and high availability, do they have to get their stream data independantly or can they share the same source (I assume the source cannot broadcast to two targets and I do not have my own message broker to publish/subscribe). Is this the reason for the remote adapers ? Is this the only way ?
May you please clarify what do you mean by two Server instances that "share the same source?".
The Remote Adapters were not introduced because of this kind of requirements and indeed each Remote Server instance is meant to feed exactly one Lightstreamer Server instance.
@rsouissi, Wrote:
4) New question: is it possible to start lightstreamer server without a network connection ? It seems it always needs it to check the license remotely, but this handicapes me quite often either because I use dialup where I am or because of proxy/firewall blocking your IP...
If you own a trial account, then a license check is performed at each Server startup and this requires a brief connection to the remote license server.
The connection to the remote license server is a simple HTTPS connection and we assume that it should not be blocked by firewalls.
If the Server is behind a proxy, then it can be configured in order to properly access the proxy (see the lightstreamer_conf.xml file).
If you own a Dev/Test/Prod/Demo license, on the other hand, no connection to the remote license server is needed.
@rsouissi, Wrote:
5) New question: sendMessage() is good to notify MetaAdapter but sometimes we might need to use it in request/reply mode (basically expect answer back). Is this possible somehow ? I thought maybe to get the client to subscribe to a special item identified by a random unique id where the replies would come thru, but this looks as a hack to me.
As Lightstreamer Server is meant to always stand beside a Web Server, the management of any request/reply behaviour can be left to the Web Server.
The sendMessage() method was introduced only as a shortcut for simple cases, but even our interactive demos, like the
Interaction Demo are based on servlets for the management of the user input.
Dario