Yes, I know : I asked the question :-) That time I feel I needed more implementation precision.
Unfortunately, we ends up without enough time on that iteration and I'll have to use a design I didn't wanted to use originally : a state on the server. So we're using JEE classical session where we only store a User object and a filter to check the session and the User object. So, we have a state but a really small state and more important, that state do not spread everywhere in our code but only one place. I really hope I'll have money to change that ASAP to a stateless server design. Thanks for all your answers ! On Nov 16, 2009, at 22:40 , Burak Arslan wrote: > > i just wanted to drop a note that a thread with a very closely related > subject can be found here: > > http://www.mail-archive.com/qooxdoo-devel@lists.sourceforge.net/msg18152.html > > best > burak > > Helder Magalhães wrote: >> 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 >> > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
