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
