I have something very similar to this (haven't we all written something like
this at some point?). I would love to see your forms package that includes JS
validation though. That's the one piece I'm missing. I know there are
packages out there that do the validation, but having it included in a Tcl
package for me would be really sweet.
Any chance of sharing it?
On Jan 8, 2013, at 1:39 AM, Karl Lehenbauer <karllehenba...@gmail.com> wrote:
> This talk of new capabilities for a new release of Rivet has had me
> revisiting something I've been thinking about for quite a while...
>
> It's really easy for developers to use forms in a way that they shouldn't,
> putting stuff in hidden fields, etc, that could easily be monkeyed with by an
> attacker. That data needs to be kept server side and accessed with an
> opaque, unguessable session ID cookie or equivalent. Yes, yes… clear, but
> not simple, and that friction helps to cause the observed problem.
>
> It's also super common for developers to accept input from forms with
> insufficient checks on the validity of the input data, the source of SQL
> injection attacks and so forth.
>
> I'm thinking of what you might call a response broker. (This isn't an
> original idea -- I've read about stuff like this.)
>
> Rather than doing a load_response, the page handling the response would
> explicitly name the fields you expect to get from the form, you invoke a proc
> specifying the fields you expect to find, their data types, optional code to
> validate them, and an array to stuff the validated fields into.
>
> set wantVarList {{username string} {id integer} {uid check_routine
> validate_uid} {password check_routine validate_password} {hash base64} {email
> email}}
>
> set status [response_broker $wantVarList response]
>
> Since every page using the response broker would need to check for response
> broker parse failures it would probably be nice to be able to specify a
> general handler routine that would run and then abort the page, removing the
> need to check the return.
>
> Now if I run…
>
> response_broker $wantVarList response
>
> …if the page continues then the response array would contain validated fields
> found in the form for the variables named in wantVarList and no others. You
> might want the presence of unexpected fields to also blow out, but that would
> be likely to bite you pretty often when the reasons are harmless. Maybe log
> them and include a {field ignore} option that will inhibit logging for
> expected-but-ignored fields.
>
> We've done a form package at FlightAware that has a specific look and feel
> that allows you to specify both Tcl and Javascript validation code. Of
> course you still need the Tcl code on the server but it's nice in the modern
> era to also provide Javascript validation on the browser. We could probably
> open source if its appearance was genericized or something, but I mention it
> mainly to point out the usefulness of such an approach both for the developer
> and the users and a likely need to push Rivet into providing more stuff to
> support developers making modern websites.
>
>
