On 24 Nov 2008, at 09:10, Burak Arslan wrote: > 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. Sure. > >> 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 You right. > > 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 It is impossible, I agree, but we can try to make it as hard as possible > > current technology. with a platform-bound regular desktop app, it > would > be possible. how? [1] has an answer. I'll have a look, just in case there are some ideas that could apply to qooxdoo client. > >> 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 Don't mix HTTP session and data sync, this is 2 differents things.
Consider all the rest as a (interesting) parenthesis, as it is not link to the subject : how to secure stateless server. ( The architecture I have in mind and that I should have described to be clear is the following : 1 load balancer : the backend entry point for all incomming HTTP request. * servers that process business logic, SQL access, ... 1 database server Because there is only one database server, you don't have to sync data. In case I would have to, I'll rely on database replication to do it. > > to handle the syncronization issue, using some form of distributed > lock About the lock, this is another different problem : several end user that update the same data. Nothing to do with architecture and HTTP session. I'm a big fan of the "optimistic locking" pattern > > 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, I see what you mean it's doable, but forget all that for me ! I'll let the DB replicate itself or I'll use only one DB. I don't want to fall in the NIH antipattern (Not Invented Here). [CUT] ) ------------------------------------------------------------------------- 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
