+++ 3) The attribute "pass" in the Server Entity must be FetchType.Lazy and the insert/update method in the UI/ServerDao must be so modified that the Server's Entity password is only changed when explicitly set. Otherwise we would need to create a ServerDTO and use that everywhere where a Server Entity is send to a client. That would also be the same for the Wicket UI. We can't send a blank password to the UI.
Sending passwords to the client is a no go. Not even in the admin UI. Anybody could listen/trace the http traffic and read the passwords (that are not even MD5 hash'ed cause we need to know it to login from one server to another, for example to a kick a user in another node in the cluster). The pass should never be read anywhere. If we need to check the pass or really need it somewhere we should use a special "JOIN FETCH" query to read it exceptional). It will be still a doubt for our future. Storing blank passwords in the database is just no good idea. Is there an alternative that we have? Sebastian 2013/2/4 seba.wag...@gmail.com <seba.wag...@gmail.com> > I would like to share the progress in the Cluster API. > For a design overview see: > > https://cwiki.apache.org/confluence/display/OPENMEETINGS/Cluster+Master-Slave+overview > > Status: > The database session cache as alternative to the memory session cache does > work now (with a single server and the serverId commented out in the Spring > config). > So you can configure the Client to be stored in memory or in database via > Spring config. > > What needs to be done: > 1) There are some places in the code where there is a hardcoded "null" for > the serverId. For example when updateing a Client. This was because in a > former iteration of the Cluster API "null" meant the Client is on > "localhost". In the new API, the serverId should be always read from the > org.apache.openmeetings.session.ServerUtil, which then reads it from the > Spring config. > And in the future, when the server is in cluster mode, there is no "null" > used anymore, serverId null simply means that there is no cluster > configured. > It might makes sense to throw an Exception upon startup: > If serverId == null and serverDao.getServers().size() > 0 => throw > Exception(" You have to configure a server for this instance to run the > cluster correctly). > + the serverId in the Spring config should become the "serverAdress" > > 2) There has to be a "clever" clean up job in the client table each time > the server starts up. > Cause what can happen now is: If a server is shut down you still have > entries in the client table. The next time the server is startup, those > clients are of course no more online. But the server does not know. > A simply "delete all" will not work, cause in a cluster you will have > multiple servers writing to the same database, and you can't "delete all" > because some servers might be still online. > So this is a bit tricky. > The idea would be: If the serverId is NULL (meaning no cluster configured) > It is save to delete all records in the clients-table upon server start > If the serverId is NOT NULL (cluster mode), then it you can still clean up: > - All clients with the serverId of the current server starting up > (cause no client can be already connected to a server that just boots) > - All clients that are assigned to a serverId in the tables > "servers" that either does not exist or where the server is flaged as "not > active". > - All clients that have a serverId null > > From my point of view those are the most important things for the session. > > The other issue is with the whiteboard. Whiteboard is stored in memory too > (because sync method is involved). > A conference room is always inside the same node of the server. But what > could happen is, that the cluster gives the room upon the next day/meeting > to another server/node in the cluster. > Then the previously written stuff on the whiteboard would be gone (or by > random chance if the same server is taken, you might get the same > whiteboard session object again). > Short story: The whiteboard session must be made configureable to be in > database too. And there has to be some clever trick to have only small > effects to the performance while syncing. > > What about the chat, I have seen you made some changes to the chat lately > Maxim? Is the Chat in the dashboard now in the database? > > Sebastian > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
