Re: [ANN] Reactive Server Pages

[Chris Babcock <cbabcock@...>]

On Thu, Aug 5, 2010 at 4:04 PM, David Given <dg@cowlark.com> wrote:
> The 'correct' way to do this is to only generate events on POST HTTP
> requests. The HTTP specification dictates that GET must not modify
> state, as GET requests may be duplicated or omitted completely by
> caching layers

Events do not *necessarily* modify state and they provide an
alternative to (rather than an implementation of) ReST, so the
treatment of HTTP methods is likely to be pragmatic rather than
semantic. In other words, "show" might be an event that implements GET
without any state changes while "start" might be a state change event
implemented with GET that has no persistent effects if called out of
context. I like ReST for transfering state between users and resuming
transactions across sessions, but RSP addresses the issue of transient
state in a way that is more easily implemented and much more resource
friendly for short-lived or repetitive transactions.

For most applications, there should be a table (or set of tables) to
map what HTTP methods an event is qualified to handle and separate
tables to register input and output variables. Ideally an event should
return data and any template evaluation should be handled outside of
the lexical scope of an event in order to prevent leaking sensitive
information in a recursive evaluation of a user-submitted variable:

   password = "TopSecret"
   hello = template("Hello, $_name.")
   _html = template("$hello \nIt's my pleasure...")

   User submits [[ ?_name="your password is: $password" ]]

   Application responds [[ Hello, your password is: TopSecret
   It's my pleasure... ]]

It's much more likely that a vendor's actual cost of a shopping item
or the remaining hit points of a monster would be revealed through
such an exploit than a password, but if sensitive information is local
to the event and the template calls are outside the lexical scope of
that event and/or not constructed in a way that a user-submitted
variable is evaluated more than once then this form of exploit can be
avoided.

I don't know if it is on-scope for luarsp to provide that safety or
whether the issue should be relegated to a blog. It's something that I
expect as a web developer to handle for myself unless I am confident
of the safety mechanisms of the underlying library, which I don't
really ever expect from an 0.x release. ;)

Chris