Hello Jean-Baptiste, thanks for sharing your interesting thoughts.
1. I think thats quite impossible to get a real secure solution because you can not have a "real" secret on the client side. But i guess you can get security by obscurity. :) If you place your app only in a optimized build version on the web, it sure is hard to get the function calls and the javascript function at all. Perhaps you could use that fact and just generate an id in a function which matches a special pattern. On the serverside you can check that because you have the same information. I guess the patter could be something easy like "time * 123 % 123456789". But one thing is for sure, if someone gets that function, the security is done. So no real security! But perhaps you could du it like google and their maps API, just use for the url in that id generating function. 2. I guess that the best solution to get. Perhaps you have to get user spesific information anyway most of the time so its just the check for the password which ist extra. In the end im not a security expert so i would be happy if somebody could proove me wrong, especially on the first question. Best, Martin Am 23.11.2008 um 09:50 schrieb Jean-Baptiste BRIAUD -- Novlog: > Hi, > > 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 ? > > OK, let's build a stateless backend that manage data transaction but > then, how to ensure security ? > > 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 ? > > 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. > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
