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" <[email protected]> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
