cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: ROP, server-side state and "session fixation problem"
Date Fri, 14 Sep 2012 02:24:39 GMT
My ROP app unfortunately got canned, but I had created a custom login
message (along with some others) that contained the username and password.
 If correct if would store the User object in the session and then check
for it on subsequent requests.

There is quite a bit to be done to properly secure an ROP service even
beyond authentication.  You really want to be able to limit what queries
are able to run and which objects can be accessed, and there is no standard
approach for handling this.  I modeled my approach after what WebObjects
did, but I didn't complete it.

On Thursday, September 13, 2012, Andrus Adamchik wrote:

> Have a bit of an issue with ROP and the latest containers:
>
> https://issues.apache.org/jira/browse/CAY-1739
>
> Essentially with BASIC auth we can no longer force the ROP client to
> return back to the same session between requests. Both recent Tomcat and
> Jetty would reset session ID on every request (as every request is under
> BASIC auth protection). A workaround now is special Tomcat configuration to
> disable session resets. We can and should document it, but ideally I'd like
> ROP to work anywhere out of the box.
>
> We can't reliably track the changing session ID on the client, as it will
> create a client-side race condition.
>
> Long term I think we should reserve BASIC auth for the stateless apps (why
> create a server side session if we can create a Cayenne stack for every
> request on the fly). We don't have a stateless option in ROP and this is a
> shame.
>
> So the question is what to do for stateful apps (and specifically in 3.1
> where all ROP apps are stateful by definition)? Anyone has implemented ROP
> auth other than BASIC? (Otherwise I don't understand how this problem
> wasn't noticed till now).
>
> Andrus
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message