Active Scaffold team, please clarify framework's session usage

[rovnak]

In previous thread

http://groups.google.com/group/activescaffold/browse_thread/thread/49c557db429b1390/#

I discussed that there are well known issues with relying on server
side session for page specific values. This is generally a bad recipe.

Can someone from the ActiveS team clarify what, if anything, is stored
in server side session (i.e. rails session)?

Specifically, I know that earlier versions of AjaxS were vulnerable to
the classic page <-> session mismatch problem. i.e. user submits one
page of sub page and the controller appliies incorrect logic to the
processing of the page because it is relying on server side session.

Think of a classic shopping cart application. The server does not know
which "product detail" page the user is looking at when the user
clicks on "add to cart", unless that page submits an identifying value
(usually a hidden value) back to the server with the query string or
post params. That is the right way to do it.

If instead, the application assumes "oh, the user is looking at only
one product detail page at a time, therefore I will store the product
id in the server session and ASSUME that when I recieve an add to cart
request that it must refer to the last page I rendered" ...well that
is a recipe for disaster. That is a totally innapropriate use of
server side session.

It is SUPER SUPER critical for the ActiveS engineers to clarify if
they rely on server side session in any fashion that would open the
app up to such vulnerabilities - whether it be on updates, pagination,
lists, whatever. Any action can be compromised if it relies on
innappropriate server side session. And one will typcially not notice
the problem during unit testing because it will appear to work
correctly for a single user working with a single browser or tab.

[rovnak]

Let me clarify. I am not saying that Active S has problems with
incorrect server side session usage ... I am only ASKING if there are
any known issues and I am asking if the development team is convinced
that there are none.

I mentioned it because there is A LOT of black magic in Active
S ...which is both good and bad thing. Very poweful, but also
mysterious.

I specifically recall that one of the earlier Ajax S tutoriasl /
demos included a comment about "this relies on session values ...
you will have to rework it if you do not want to rely on session" - I
think it was one of the examples of nested scaffolds in particular,
that was assuming the end user had only one nested scaffold open at a
time ... which I thought was not a valid assumption.

This is why I am asking the question. I know Active S is not the same
as Ajax S but it evolved from it.

On Apr 12, 11:19 am, "rovnak" <donloga...@gmail.com> wrote:
> In previous thread
>
> http://groups.google.com/group/activescaffold/browse_thread/thread/49...

[Lance Ivy]

Some of the things we store in the session are from the browser, and some are from the developer. All session settings are indexed either by controller or by a unique id generated for embedded scaffolds (the eid). We get the current session index via params[:eid], which normally is completely hidden from the user due to the nature of render_component calls. It's possible for someone familiar with params[:eid] to try and "hack" ActiveScaffold and access the settings for a different scaffold, but I'm convinced this would provide no benefit for the hacker except to create an exception or to end up on the wrong page. Any scaffold settings indexed in the browser's session are permitted for the user by virtue of their benign nature.

From the browser, we store:
  * results per page (which is actually not configurable from the UI yet)
  * current page
  * current sorting

From the developer, we store:
  * constraints (which are powerful and we would never want the user to define ... thankfully these are defined by the dev and saved)
  * the list label for embedded scaffolds

Other things we may conceivably store from the browser in the future:
  * the current search term
  * the list of visible columns (filtered according to a whitelist of allowed columns)

So yes, we do store some state variables from the browser that may interfere with multi-threaded navigation of the same scaffold, but I am convinced that any problems this causes will be a sub-optimal user experience and not a vulnerability ( e.g. unintentionally skipping to the wrong page in one of the windows).

I don't think that storing benign state information in the session is a bad thing. For the single-threaded use case, it can very helpful to return to the scaffold and not lose your place. I believe that the usage of session storage in a CRUD tool is a matter of optimizing for single-threaded vs multi-threaded use cases, and even if most of your particular users prefer to use multiple windows I believe that the most common use case is the single-threaded case.

-Lance

p.s. You're welcome to print a session dump and see what's in the session at any given point, and if you think any of it opens up any vulnerabilities then please contact us!

[rovnak]

Thanks for the complete reply Lance.

I guess my biggest concern is unintentional updates or deletes, where
the user is looking at one record, invokes an update or delete and the
action is applied to a completely different record.

As I become more familiar with Rails, I will be able to observe the
session usage better myself by looking at the session dumps etc.

> vulnerability (e.g. unintentionally skipping to the wrong page in one of the

> windows).
>
> I don't think that storing benign state information in the session is a bad
> thing. For the single-threaded use case, it can very helpful to return to
> the scaffold and not lose your place. I believe that the usage of session
> storage in a CRUD tool is a matter of optimizing for single-threaded vs
> multi-threaded use cases, and even if most of your particular users prefer
> to use multiple windows I believe that the most common use case is the
> single-threaded case.
>
> -Lance
>
> p.s. You're welcome to print a session dump and see what's in the session at
> any given point, and if you think any of it opens up any vulnerabilities
> then please contact us!
>