Jean-Baptiste BRIAUD -- Novlog wrote: > Hi, > > hey > I'd like to share some thought, please don't hesitate to give feedback. > > Thanks to qooxdoo, it is possible to maintain application state(s) on > client side. > So, why bother with HTTP session on backend ? > > uh... > OK, let's build a stateless backend that manage data transaction but > then, how to ensure security ? > > yeah, you have to have some form of authentication. > 1. server security : how to ensure that only qooxdoo frontend is able > to make call > => no idea there ... maybe some magic number returned by any call and > that should be given back for next call or something like that ? > I'm afraid that would force server to maintain a context and then HTTP > session that I would like to kill. > Any idea ? > > this sort of problem is not present only with qooxtoo type of apps. i don't want to go into detail here, but i've done the research, and what you're asking for is impossible for a javascript app considering the current technology. with a platform-bound regular desktop app, it would be possible. how? [1] has an answer. > 2. application security : how to ensure only logged users can play > with application > => Maybe the solution could be to pass user/password as two first > parameters on each call, so the server would check the user is allowed > without maintaining a state of logged users. > This would cause a little performance cost but that could be done in > memory to optimize without needed a server state. > > In fact, one could wonder why I want so hard to kill that HTTP session > on server side ... > The answer is simple : to scale. When server is stateless, > loadbalancing become obvious. > > no it doesn't, unless your data is absoutely read only. you still have to handle the syncronization issue, using some form of distributed lock management. you can do this yourself, or let the rdmbs handle it. dlm is a hot research area, but the simplest way to do this is to route insert and updates thru one master, that progressively propagates changes to the slaves. this is called master-slave replication, and is also used as a high availability measure. (when the master fails, one of the slaves takes over the role of the master). but what to do when even the master's capacity is saturated? that's when you'll need a serious multi-master replication solution, so it's time so spend serious money on either development of such an engine, or on licensing of an existing one.
yeah, one heck of a problem. > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > take care burak [1]: http://suif.stanford.edu/papers/sosp03-terra.pdf ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
