Hi,

Others can correct me but if you want the server side to be completely
stateless then you can drop login step and have to instead include user name
and  password as part of every "normal" request. To remember the user
between the sessions you can save and read a cookie that contains user
credentials. Cookie would be managed completely from Qooxdoo application.

In general copy/paste attack is possible, valid cookie is the sole key that
is usually needed to login to common web services. If the user doesn't trust
to the used computer he should not allow storing that kind of cookie (i.e.
check remember me option)

         -ilkka

On Thu, Nov 12, 2009 at 8:03 PM, Jean-Baptiste BRIAUD -- Novlog <
j-b.bri...@novlog.com> wrote:

> Hi the list,
>
> How do you manage authentication of user on stateless servers environment ?
>
> I have Java backend but don't want to use HTTP session on server side : I
> want to maintain servers stateless.
> (this is because it scale better, but the reason doesn't matter here).
>
> 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.
>
> 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 ?
>
> Questions :
>
> * Do you use a cookie ? If yes, what do you put in that cookie ?
> How do you check authentication on server side ?
>
> * 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 ?
>
> * 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.
>
> * How do you protect, if you protect, against javascript or more generally
> against client-side hacking : DOM modification, javascript modification, ...
>
> Thanks !
>
> ------------------------------------------------------------------------------
> 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
>



-- 
+358 50 486 0721
------------------------------------------------------------------------------
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

Reply via email to