[Tcl Wiki] Update of "RivetProposals" by MassimoManghi

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tcl Wiki" for change notification.

The "RivetProposals" page has been changed by MassimoManghi:
https://wiki.apache.org/tcl/RivetProposals?action=diff&rev1=5&rev2=6

  
   Karl wishlist's open points:
  
+  * a load_response transaction-type thing
+ 
+  From the original message sent to rivet-dev@tcl.apache.org
+ 
+ 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.
  
   * Named separate virtual interpreters.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: site-cvs-unsubscribe@tcl.apache.org
For additional commands, e-mail: site-cvs-help@tcl.apache.org