Yes. Look at how its done by Struts and the Apache Commons Validator
platform.
-dhs
Dean H. Saxe, CISSP, CEH
d...@fullfrontalnerdity.com
"Dissent is the purest form of patriotism."
--Thomas Jefferson
On Mar 10, 2009, at 12:35 PM, Mischa Uppelschoten ext 10 wrote:
Sorry for the confusion. My point is that even though the server
does perform validation, it does so only at the command of the
client (hidden field). Effectively, it is therefore still client
side validation. I believe it gives a false sense of security (to
myself included) since it's so easily bypassed by anyone with some
basic tools, so I'm glad Dean pointed it out. Because he wrote that
he wasn't 100% sure, I decided to test it and share my code. I
didn't mean to convey any sort of concern about the absence/presence
of hidden form fields.
Do you think in theory CF could provide true server side validation
without relying on hidden form fields? My guess would be "yes in a
fairly reliable fashion", but I'm curious if anyone has an opinion
on that...
Hope that makes sense.
/m
: Mischa, I'm curious what you're getting at here. Perhaps I missed
part of
: what was being traded, but I was actually surprised by the
assertion Dean
: made (that you repeated). CFInput does NOT *always* use a hidden
field to
: force server-side validation. It only does that if you ask it to,
using the
: ValidateAt="onserver", as you show. If you don't specify that, it
doesn't
: add any hidden fields.
: Or are you guys making a different point, about what it is that CF
does
: create as that hidden field when you ask it to (using that
attribute)?
: I'm just trying to understand that, and also your subject line,
which seems
: to be asserting yet something different (that it's only client
side).
: Help us out. It may just be me that's confused. :-)
: /charlie
: -----Original Message-----
: From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Mischa
: Uppelschoten ext 10
: Sent: Monday, March 09, 2009 3:05 PM
: To: Web Site
: Subject: ValidateAt parameter is effectively only client side
(was: "re[2]:
: [ACFUG Discuss] Password CFinput regular expression - throws alert/
error
: after correction also")
: : IIRC cfinput will always use a hidden form field on the client to
: : force server side validation.
: Dean is right:
: <cfif isdefined("form")>
: <cfdump var="#form#" show="MyNumber">
: </cfif>
: <cfform name="cfformtest">
: <cfinput type="Text" validate="integer" validateat="OnServer"
: name="MyNumber">
: <cfinput type="Submit" value="submit" name="Submit">
: </cfform>
: <form name="RegularForm" method="post">
: <input type="Text" name="MyNumber">
: <input type="Submit" value="submit" name="Submit">
: </form>
: You can submit whatever you want using the second form.
: I'm a bit disappointed because Adobe seems to have thought of and
made an
: effort to prevent a similar situation with their Ajax
implementation:
: _cf_clientid is appended to the url for each http request.
: /m
: -------------------------------------------------------------
: To unsubscribe from this list, manage your profile @
: http://www.acfug.org?fa=gin.edituserform
: For more info, see http://www.acfug.org/mailinglists
: Archive @ http://www.mail-archive.com/discussion%40acfug.org/
: List hosted by http://www.fusionlink.com
: -------------------------------------------------------------
: -------------------------------------------------------------
: To unsubscribe from this list, manage your profile @
: http://www.acfug.org?fa=login.edituserform
: For more info, see http://www.acfug.org/mailinglists
: Archive @ http://www.mail-archive.com/discussion%40acfug.org/
: List hosted by http://www.fusionlink.com
: -------------------------------------------------------------
---------- Original Message ----------
FROM: "Charlie Arehart" <char...@carehart.org>
TO: <discussion@acfug.org>
DATE: Tue, 10 Mar 2009 11:53:02 -0400
SUBJECT: RE: ValidateAt parameter is effectively only client side
(was: "re[2]: [ACFUG Discuss] Password CFinput regular expression -
throws alert/error after correction also")
Mischa, I'm curious what you're getting at here. Perhaps I missed
part of
what was being traded, but I was actually surprised by the assertion
Dean
made (that you repeated). CFInput does NOT *always* use a hidden
field to
force server-side validation. It only does that if you ask it to,
using the
ValidateAt="onserver", as you show. If you don't specify that, it
doesn't
add any hidden fields.
Or are you guys making a different point, about what it is that CF
does
create as that hidden field when you ask it to (using that attribute)?
I'm just trying to understand that, and also your subject line,
which seems
to be asserting yet something different (that it's only client side).
Help us out. It may just be me that's confused. :-)
/charlie
-----Original Message-----
From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Mischa
Uppelschoten ext 10
Sent: Monday, March 09, 2009 3:05 PM
To: Web Site
Subject: ValidateAt parameter is effectively only client side (was:
"re[2]:
[ACFUG Discuss] Password CFinput regular expression - throws alert/
error
after correction also")
: IIRC cfinput will always use a hidden form field on the client to
: force server side validation.
Dean is right:
<cfif isdefined("form")>
<cfdump var="#form#" show="MyNumber">
</cfif>
<cfform name="cfformtest">
<cfinput type="Text" validate="integer" validateat="OnServer"
name="MyNumber">
<cfinput type="Submit" value="submit" name="Submit">
</cfform>
<form name="RegularForm" method="post">
<input type="Text" name="MyNumber">
<input type="Submit" value="submit" name="Submit">
</form>
You can submit whatever you want using the second form.
I'm a bit disappointed because Adobe seems to have thought of and
made an
effort to prevent a similar situation with their Ajax implementation:
_cf_clientid is appended to the url for each http request.
/m
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=gin.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------