Heck yes!
On 9/23/16, 3:22 PM, "Massimo Manghi" <mxman...@apache.org> wrote:
Thank you Karl, can I rework it and put in a package to be added to the
rivet Tcl library?
-- Massimo
On 09/23/2016 06:52 PM, Karl Lehenbauer wrote:
> Yeah we too have been working on this once again. Basically take an
> array created by load_response and invoke procs to validate,
> sanitize, etc. The procs generate errors like if any of a specified
> list of fields that are supposed to be integer, aren’t, and Tcl 8.6’s
> try…trap is handy for wrapping them all together into one try body,
> handling any error with the trap arm. Also they can be used
> unguarded, let the error trace back to Rivet, and have the Rivet
> error handler recognize the errorCode and do something appropriate.
>
>
>
> I’ve pasted a chunk of that stuff below, but we are instead going to
> make something similar that validates, copies, sanitizes stuff from
> the response array into a second array that’ll be used by the code to
> do whatever.
>
>
>
> #
>
> # response_security_error - issue an error with errorCode
>
> # set appropriate -- we expect the rivet error handler
>
> # to catch this and do the right thing
>
> #
>
> proc response_security_error {type message} {
>
> error $message "" [list RIVET SECURITY $type $message]
>
> }
>
>
>
> #
>
> # require_response_vars - error if any of the specified are not in
> the response
>
> #
>
> proc require_response_vars {_response args} {
>
> upvar $_response response
>
>
>
> foreach var $args {
>
> if {![info exists response($var)]} {
>
> response_security_error MISSING_VAR "var $var not present in
> $_response"
>
> }
>
> }
>
> }
>
>
>
> #
>
> # force_response_integers - error if any of named vars in response
> doesn't exist
>
> # or isn't an integer
>
> #
>
> proc force_response_integers {_response args} {
>
> upvar $_response response
>
>
>
> require_response_vars response {*}$args
>
>
>
> foreach var $args {
>
> if {![regexp {[0-9-]*} response($var)]} {
>
> response_security_error NOT_INTEGER "illegal content in $var"
>
> }
>
>
>
> if {![scan $response($var) %d response($var)]} {
>
> response_security_error NOT_INTEGER "illegal content in $var"
>
> }
>
> }
>
> }
>
>
>
> #
>
> # force_response_integer_in_range - error if var in response isn't an
> integer
>
> # or if it isn't in range
>
> #
>
> proc force_response_integer_in_range {_response var lowest highest}
> {
>
> upvar $_response response
>
>
>
> force_response_integers response $var
>
>
>
> if {$response($var) < $lowest || $response($var) > $highest} {
>
> response_security_error "OUT_OF_RANGE" "$var out of range"
>
> }
>
> }
>
>
>
> #
>
> # force_quote_response_strings - sanitize and pg_quote all the
> specified strings in the array
>
> #
>
> proc force_quote_response_strings {_response args} {
>
> upvar $_response response
>
> force_sanitize_response_strings response {*}$args
>
>
>
> foreach var $args {
>
> set response($var) [pg_quote $response($var)]
>
> }
>
> }
>
>
>
> #
>
> # force_quote_response_unfilteredstrings - rewrite named response
>
> # elements pg_quoted
>
> #
>
> proc force_quote_response_unfilteredstrings {_response args} {
>
> upvar $_response response
>
> require_response_vars response {*}$args
>
>
>
> foreach var $args {
>
> set response($var) [pg_quote $response($var)]
>
> }
>
> }
>
>
>
>
>
> On 9/23/16, 11:20 AM, "Massimo Manghi" <mxman...@apache.org> wrote:
>
>
>
> Years ago Karl proposed to develop a form data validator he called
>
> 'response broker'. (The message is at [1]) Damon answered quite
> rightly
>
> "haven't we all written something like this at some point?"
>
>
>
> I'm now working on a refactoring of an application and I'm striving
> to
>
> redesign it in a way to have an emphasis on object collaboration
> rather
>
> than long and complicated methods. (I want to convince someone to
> adopt
>
> it by enticing him into working with a set of easy to read and
>
> understand classes)
>
>
>
> Form data validation became soon one of the sore points: I can't
> imagine
>
> a method for validation that can match safety and completeness
> without
>
> being cumbersome, repetitive or, in a word, boring to work with
>
>
>
> Much more exciting would be working on a real validator that solves
> to
>
> some extent the general problem.
>
>
>
> Has anyone worked on Karl's idea? Am I inexorably about to set out
> to
>
> reinvent the wheel?
>
>
>
> -- Massimo
>
>
>
> [1]
>
>
http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/201301.mbox/%3CDA2C5384-232C-4377-B35C-A91E8FA348C6%40gmail.com%3E
>
