Hi Jean,
Jean-Baptiste BRIAUD -- Novlog wrote: > > How do you manage authentication of user on stateless servers environment > ? > The most simple (and probable most effective) method is using HTTP authentication. This causes the client to send the authentication information with each request, and the server one needs to check the information with its database. Most (at least all major) web servers support this authentication scheme. This may have a few lacunas (and workarounds) though: * It's hard to force a logout, as the browser (by default) caches the credentials provided in the first authentication prompt. But there are ways [1] to "help" the browser forgetting about them... * Some people say it's not very secure as the credentials are send to the server in a weak encryption format. This can be worked around using digest authentication, though some simpler (mobile/older) browsers don't support it. Also, one can (and should) force the use of HTTPS in high security environments. Jean-Baptiste BRIAUD -- Novlog wrote: > > 1. Login > So, I have a form to ask for login/pass to end-user, then it hash the pass > and send login/hashedpass to the server. > On server side, we can check that this end-user is authorized. > The default login prompt usually can't be personalized (it's created by the browser), although there are some tricks [2] which basically consist in capturing the credentials and send the first request using an AJAX approach with the authentication information. Jean-Baptiste BRIAUD -- Novlog wrote: > > 2. Using the server > Now I send a request to do some business, how do you ensure that RPC > request correspond to an authenticated end-user ? > The web server takes care of that, and using its API you may fetch who is it if some operations are reserved to some users... Jean-Baptiste BRIAUD -- Novlog wrote: > > * Are you also doing something on client side with that cookie ? > > * Could that be as simple as copy/paste the cookie to another machine to > bypass security ? > How do you protect against that copy/past attack ? > > * How do you protect, if you protect, against javascript or more generally > against client-side hacking : DOM modification, javascript modification, > ... > As far as I know, HTTP authentication doesn't suffer from this kind of attacks... Jean-Baptiste BRIAUD -- Novlog wrote: > > * Don't forget that due to good qooxdoo RPC design, requests are > individually asynchronous and sent in parallel, and we are using that > heavily. > I add that because apparently, adding some random and/or crypted value to > the RPC request that the server would eventually controlled doesn't work. > This is because you can't ensure that all RPC thread will share the value > changed on the server side. > HTTP-based authentication is managed by the browser, therefore no worries regarding client-server communication. Hope this helps, Helder [1] http://www.berenddeboer.net/rest/authentication.html#permanent-logout [2] http://www.berenddeboer.net/rest/authentication.html#login-page -- View this message in context: http://old.nabble.com/authentication-tp26323410p26373154.html Sent from the qooxdoo-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
