[fw-general] Zend_Form - should data validation occur on filtered value?
Hi Matthew and every body, First a use case: On an i18n application the user can chose is preferred date format for display and input. Let’s say 'dd/MM/'. I n the backend I will need a validator to validate the date format and a filter to convert the date to a Mysql format '-MM-dd'. But here the validation against 'dd/MM/' won’t work because the date will be filtered before validation. Well, an easy work around will be to validate against the '-MM-dd' format but it sound not very clean and I could not use an error message saying the right format to use. So I’m wondering if data should be filtered prior to validation. Is there some security concern? While I see some advantage to filter data, like removing white space, before it is validated. It looks better to me to run it after the validation and let know the user that is input is wrong. Then filter data for formatting and security. Best Regards, -- Laurent Melmoux Annecy, France
Re: [fw-general] Zend_Form - should data validation occur on filtered value?
Hi Laurent, While I don't have the answer to your question specifically, I know that Zend_Form used to validate before filtering like you are suggesting. But that was modified per this discussion: http://www.nabble.com/Zend_Form_Element-validation-bug-tt15589810s16154.html As a side note, I've done something very similar to the use case you describe, and didn't run into this problem. The only difference I had was that the filter converts the given date to a Zend_Date instance. Which then runs through Zend_Validate_Date and it's has been working fine. Think I got lucky there and I've even noticed it :) Back to the discussion linked above, in one post I can tell that Matthew acknowledged the important of a pre/postFilter. Best Regards, - Amr On Sat, Mar 8, 2008 at 11:26 AM, Laurent Melmoux [EMAIL PROTECTED] wrote: Hi Matthew and every body, First a use case: On an i18n application the user can chose is preferred date format for display and input. Let's say 'dd/MM/'. I n the backend I will need a validator to validate the date format and a filter to convert the date to a Mysql format '-MM-dd'. But here the validation against 'dd/MM/' won't work because the date will be filtered before validation. Well, an easy work around will be to validate against the '-MM-dd' format but it sound not very clean and I could not use an error message saying the right format to use. So I'm wondering if data should be filtered prior to validation. Is there some security concern? While I see some advantage to filter data, like removing white space, before it is validated. It looks better to me to run it after the validation and let know the user that is input is wrong. Then filter data for formatting and security. Best Regards, -- Laurent Melmoux Annecy, France
Re: [fw-general] Zend_Form - should data validation occur on filtered value?
Thanks Amr, I should have search the list :) -- Laurent Melmoux Annecy, France Amr Mostafa a écrit : Hi Laurent, While I don't have the answer to your question specifically, I know that Zend_Form used to validate before filtering like you are suggesting. But that was modified per this discussion: http://www.nabble.com/Zend_Form_Element-validation-bug-tt15589810s16154.html As a side note, I've done something very similar to the use case you describe, and didn't run into this problem. The only difference I had was that the filter converts the given date to a Zend_Date instance. Which then runs through Zend_Validate_Date and it's has been working fine. Think I got lucky there and I've even noticed it :) Back to the discussion linked above, in one post I can tell that Matthew acknowledged the important of a pre/postFilter. Best Regards, - Amr On Sat, Mar 8, 2008 at 11:26 AM, Laurent Melmoux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Matthew and every body, First a use case: On an i18n application the user can chose is preferred date format for display and input. Let's say 'dd/MM/'. I n the backend I will need a validator to validate the date format and a filter to convert the date to a Mysql format '-MM-dd'. But here the validation against 'dd/MM/' won't work because the date will be filtered before validation. Well, an easy work around will be to validate against the '-MM-dd' format but it sound not very clean and I could not use an error message saying the right format to use. So I'm wondering if data should be filtered prior to validation. Is there some security concern? While I see some advantage to filter data, like removing white space, before it is validated. It looks better to me to run it after the validation and let know the user that is input is wrong. Then filter data for formatting and security. Best Regards, -- Laurent Melmoux Annecy, France
Re: [fw-general] Is there a way to set options on a tag surrounding a label?
You could do that using the ViewScript decorator with the new content
wrapping feature Matthew added few hours ago! :)
Here is your new setElementDecorators():
$form-setElementDecorators(array(
array('ViewHelper'),
array('ViewScript', array('viewScript' = 'element.phtml',
'placement' = false)),
));
Then in your element.phtml:
?php
require_once 'Zend/Form/Decorator/Label.php';
$label = new Zend_Form_Decorator_Label();
$label-setElement($this-element);
?
tr
td
?= $label-render('') ?
/td
td
?= $this-content ?
/td
/tr
One small note about the Label decorator, we could actually write the
label tag ourselves like: label for=?= $this-element-getAttrib('id')
??= $this-element-getLabel() ?/label
But that's not good enough, what if the element doesn't have 'id' set? Label
decorator is smart to fall back to the element name if id is not set, and it
has a bunch of other extras, like adding the optional/required classes,
...etc.
Best Regards,
- Amr
On Sat, Mar 8, 2008 at 4:55 AM, Karl Katzke [EMAIL PROTECTED] wrote:
I'm using Zend_Form to build a form, and I'd like to align all of the
labels to the right inside their table cells. I can do this with either CSS
or the align=right attribute of the table cell, but I would need to be
able to set attributes on the tag... which by my read, currently isn't
possible.
Sample decorator:
46 $this-setElementDecorators(array(
47 'ViewHelper',
48 'Errors',
49
array('decorator'=array('td'='HtmlTag'),'options'=array('tag'='td')),
50 array('Label',array('tag'='td')),
51
array('decorator'=array('tr'='HtmlTag'),'options'=array('tag'='tr')),
52 ));
In Zend_Form_Decorator_Label, we're already using
Zend_Form_Decorator_HtmlTag to render the tag option of the label. Could we
add a tagoptions field to that Label decorator and pass the array of options
through to the Zend_Form_Decorator_HtmlTag?
I'm a bit of a newb to Zend Framework, and this is deep enough inside the
framework to make my head spin a bit, but it looks like a fairly simple
addition. I'm just not sure how to execute it without breaking things
further! I realize that everyone's in a rush to get the last few changes in
before the freeze, but I'd appreciate a hand with this if anyone has the
time.
Thanks,
Karl Katzke
Re: [fw-general] Is there a way to set options on a tag surrounding a label?
Pardon my rush there, I need to stop assuming that everyone lives on the
subversion trunk :)
Ok so here we go: This is going to work with the current trunk only or with
the next 1.5 release candidate :)
Cheers,
- Amr
On Sat, Mar 8, 2008 at 1:01 PM, Amr Mostafa [EMAIL PROTECTED] wrote:
You could do that using the ViewScript decorator with the new content
wrapping feature Matthew added few hours ago! :)
Here is your new setElementDecorators():
$form-setElementDecorators(array(
array('ViewHelper'),
array('ViewScript', array('viewScript' = 'element.phtml',
'placement' = false)),
));
Then in your element.phtml:
?php
require_once 'Zend/Form/Decorator/Label.php';
$label = new Zend_Form_Decorator_Label();
$label-setElement($this-element);
?
tr
td
?= $label-render('') ?
/td
td
?= $this-content ?
/td
/tr
One small note about the Label decorator, we could actually write the
label tag ourselves like: label for=?= $this-element-getAttrib('id')
??= $this-element-getLabel() ?/label
But that's not good enough, what if the element doesn't have 'id' set?
Label decorator is smart to fall back to the element name if id is not set,
and it has a bunch of other extras, like adding the optional/required
classes, ...etc.
Best Regards,
- Amr
On Sat, Mar 8, 2008 at 4:55 AM, Karl Katzke [EMAIL PROTECTED] wrote:
I'm using Zend_Form to build a form, and I'd like to align all of the
labels to the right inside their table cells. I can do this with either CSS
or the align=right attribute of the table cell, but I would need to be
able to set attributes on the tag... which by my read, currently isn't
possible.
Sample decorator:
46 $this-setElementDecorators(array(
47 'ViewHelper',
48 'Errors',
49
array('decorator'=array('td'='HtmlTag'),'options'=array('tag'='td')),
50 array('Label',array('tag'='td')),
51
array('decorator'=array('tr'='HtmlTag'),'options'=array('tag'='tr')),
52 ));
In Zend_Form_Decorator_Label, we're already using
Zend_Form_Decorator_HtmlTag to render the tag option of the label. Could we
add a tagoptions field to that Label decorator and pass the array of options
through to the Zend_Form_Decorator_HtmlTag?
I'm a bit of a newb to Zend Framework, and this is deep enough inside
the framework to make my head spin a bit, but it looks like a fairly simple
addition. I'm just not sure how to execute it without breaking things
further! I realize that everyone's in a rush to get the last few changes in
before the freeze, but I'd appreciate a hand with this if anyone has the
time.
Thanks,
Karl Katzke
Re: [fw-general] Zend_Form - should data validation occur on filtered value?
I’ve read the discussion and I really agree with Matthew first answer (more below ) : Matthew Weier O'Phinney-3 wrote: Validation merely makes sure that the submitted data passes certain rules. Filtering is for output -- to a database, to the screen, whatever. You validate unfiltered data, and then filter it for your output stream. Another use for filtering is normalization -- taking input and modifying it to fit a 'normal' specification. An example of this is taking a phone number -- (800) 555-1212 -- and normalizing it for your database -- 8885551212. You will often take a normalized value and filter it again for display -- 800.555.1212. Let's look at this: If I have a filter, StripTags, and then a validator, NoTags, and run the data through the filter prior to validating what's the point of the validation then? you've already ensured that it will pass no matter what.. but now when you return the data to the user, it looks unfamiliar to them. Better is to check for tags in the first place, and let the user know they aren't allowed... or, allow them, but strip them out prior to storing or displaying the information (to prevent XSS attacks, for example). Then Matthew changed it to pre-filter base on what I've been done in ZFI For those who are interested: The idea is to allow some normalization of data prior to sending it to validation. The example given me was one of a username: * Allow only 3-16 characters and you get ' mweierophinneyzend ' as input... it would fail validation, but likely shouldn't have. If the input were run through StringTrim first, it would pass. Basically, such normalization ensures that the data is *ready* for validation. It looks to me that only StringTrim fit the use case of pre-filtering data. And I’m style convinced that post filtering is a better approaches. :) -- Laurent Melmoux Annecy, France Amr Mostafa a écrit : Hi Laurent, While I don't have the answer to your question specifically, I know that Zend_Form used to validate before filtering like you are suggesting. But that was modified per this discussion: http://www.nabble.com/Zend_Form_Element-validation-bug-tt15589810s16154.html As a side note, I've done something very similar to the use case you describe, and didn't run into this problem. The only difference I had was that the filter converts the given date to a Zend_Date instance. Which then runs through Zend_Validate_Date and it's has been working fine. Think I got lucky there and I've even noticed it :) Back to the discussion linked above, in one post I can tell that Matthew acknowledged the important of a pre/postFilter. Best Regards, - Amr On Sat, Mar 8, 2008 at 11:26 AM, Laurent Melmoux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Matthew and every body, First a use case: On an i18n application the user can chose is preferred date format for display and input. Let's say 'dd/MM/'. I n the backend I will need a validator to validate the date format and a filter to convert the date to a Mysql format '-MM-dd'. But here the validation against 'dd/MM/' won't work because the date will be filtered before validation. Well, an easy work around will be to validate against the '-MM-dd' format but it sound not very clean and I could not use an error message saying the right format to use. So I'm wondering if data should be filtered prior to validation. Is there some security concern? While I see some advantage to filter data, like removing white space, before it is validated. It looks better to me to run it after the validation and let know the user that is input is wrong. Then filter data for formatting and security. Best Regards, -- Laurent Melmoux Annecy, France
Re: [fw-general] Zend_Layout with nested layout?
I'm just playing with Zend_Layout and have a quick question. What I'd
like to do is have a three part view. I'd like my designer to design a
wrapper template that consists of the markup surrounding the output
of action views. This is exactly what Zend_Layout does so perfect! but
if possible I'd like the designer templates to exclude the doctype,
head and html and body tag stuff and stick strictly to what comes
after body. That way designers don't need to worry about the non-
design stuff.
doc.phtml:
!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html
head
meta http-equiv=Content-Type content=text/html;
charset=utf-8 /
title?= $this-headTitle() ?/title
?= $this-headScript() ?
?= $this-headStyle() ?
/head
body
?= $this-layout()-content ?
/body
/html
which includes the following designer layout.phtml in content:
div id=content
!-- renders /nav/menu --
div id=nav?= $this-layout()-nav ?/div
!-- renders /foo/index + /comment/fetch --
div id=content?= $this-layout()-content ?/div
/div
which includes the action.phtml template in content.
You could probably create a view helper like this:
class My_View_Helper_NestedLayout
{
public function nestedLayout($layoutName)
{
try {
$layout = Zend_Layout::getMvcInstance();
echo $layout-render($layoutName);
}
} catch (Zend_Exception $e) {
$this-view-layout($layoutName);
}
}
public function setView(Zend_View_Interface $view)
{
$this-view = $view;
}
}
add the helper path (see
http://framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.custom)
Usage in your main layout (doc.phtml):
...
? $this-nestedLayout('content/layout') ?
...
this would render the layout file 'content/layout.phtml' (relative to your
layout path) at the position where like to render the content.
Please correct me if this might fail in any case!
--
View this message in context:
http://www.nabble.com/Zend_Layout-with-nested-layout--tp15878224s16154p15912857.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Layout with nested layout?
I have just done something similiar, as I primarily thought this is what
Zend_Layout would do, basically I have the layout include a common header
and footer.
I know this is going back to the dark ages a little but it seemed like the
simplest fashion, and if you don't want a layout to use the standard header
and footer you simply delete the include from the layout.
I store everything in skins/layoutname and store the common header and
footer in skins/
skins
-- admin
-- default
-- header.php
-- footer.php
So each actual layout is a design in a skin, and the layout path is the
skin. For instance the default would be skins/admin/layout.php But if you
wanted a compact admin skin, you'd change the layout Zend_Layout would look
for to compact thus giving skins/admin/compact.php
Therefore the header/footer system seems to work well:
?php // Include the common header
echo $this-render('../header.php'); ?
I don't know if this is perfect and it probably has lots of downsides but it
works for me, I'm interested to hear others takes on 'skinning' with
Zend_Layout. I realise people might be dubious of having designers add the
render call, but they have to add the calls to display content so!
Simon
Jeffrey Sambells-2 wrote:
Hi All,
I'm just playing with Zend_Layout and have a quick question. What I'd
like to do is have a three part view. I'd like my designer to design a
wrapper template that consists of the markup surrounding the output
of action views. This is exactly what Zend_Layout does so perfect! but
if possible I'd like the designer templates to exclude the doctype,
head and html and body tag stuff and stick strictly to what comes
after body. That way designers don't need to worry about the non-
design stuff.
-
Simon Corless
http://www.ajb007.co.uk/
--
View this message in context:
http://www.nabble.com/Zend_Layout-with-nested-layout--tp15878224s16154p15912865.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Zend_Filter_Input 'presence'='required'
Try 'missingMessage' if you are still having problems. thurting wrote: Hi Brian, You can change the relative message by setting it as an option of your Zend_Filter_Input instance. This can be done during instantiation or through the setOptions() method. You can not set different messages for different filters/validators - only one message format per instance. You may want to use Zend_Validate_NotEmpty if you need more flexibility. There is sample code in the docs, but I will post it here to save you the trouble. ?php $options = array( 'notEmptyMessage' = A non-empty value is required for field '%field%' ); $input = new Zend_Filter_Input($filters, $validators, $data, $options); // alternative method: $input = new Zend_Filter_Input($filters, $validators, $data); $input-setOptions($options); -- View this message in context: http://www.nabble.com/Zend_Filter_Input-%27presence%27%3D%3E%27required%27-tp15865637s16154p15912885.html Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Is there a way to set options on a tag surrounding a label?
-- Amr Mostafa [EMAIL PROTECTED] wrote
(on Saturday, 08 March 2008, 01:03 PM +0200):
Pardon my rush there, I need to stop assuming that everyone lives on the
subversion trunk :)
Ok so here we go: This is going to work with the current trunk only or with
the
next 1.5 release candidate :)
And it's also committed to the 1.5 release branch. :-)
On Sat, Mar 8, 2008 at 1:01 PM, Amr Mostafa [EMAIL PROTECTED] wrote:
You could do that using the ViewScript decorator with the new content
wrapping feature Matthew added few hours ago! :)
Here is your new setElementDecorators():
$form-setElementDecorators(array(
array('ViewHelper'),
array('ViewScript', array('viewScript' = 'element.phtml',
'placement' = false)),
));
Then in your element.phtml:
?php
require_once 'Zend/Form/Decorator/Label.php';
$label = new Zend_Form_Decorator_Label();
$label-setElement($this-element);
?
tr
td
?= $label-render('') ?
/td
td
?= $this-content ?
/td
/tr
One small note about the Label decorator, we could actually write the
label tag ourselves like: label for=?=
$this-element-getAttrib('id')
??= $this-element-getLabel() ?/label
But that's not good enough, what if the element doesn't have 'id' set?
Label decorator is smart to fall back to the element name if id is not
set,
and it has a bunch of other extras, like adding the optional/required
classes, ...etc.
Best Regards,
- Amr
On Sat, Mar 8, 2008 at 4:55 AM, Karl Katzke [EMAIL PROTECTED] wrote:
I'm using Zend_Form to build a form, and I'd like to align all of the
labels to the right inside their table cells. I can do this with
either
CSS or the align=right attribute of the table cell, but I would need
to be able to set attributes on the tag... which by my read, currently
isn't possible.
Sample decorator:
46 $this-setElementDecorators(array(
47 'ViewHelper',
48 'Errors',
49 array('decorator'=array('td'=
'HtmlTag'),'options'=array('tag'='td')),
50 array('Label',array('tag'='td')),
51 array('decorator'=array('tr'=
'HtmlTag'),'options'=array('tag'='tr')),
52 ));
In Zend_Form_Decorator_Label, we're already using
Zend_Form_Decorator_HtmlTag to render the tag option of the label.
Could we add a tagoptions field to that Label decorator and pass the
array of options through to the Zend_Form_Decorator_HtmlTag?
I'm a bit of a newb to Zend Framework, and this is deep enough inside
the framework to make my head spin a bit, but it looks like a fairly
simple addition. I'm just not sure how to execute it without breaking
things further! I realize that everyone's in a rush to get the last
few
changes in before the freeze, but I'd appreciate a hand with this if
anyone has the time.
Thanks,
Karl Katzke
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend_Form - should data validation occur on filtered value?
-- Laurent Melmoux [EMAIL PROTECTED] wrote (on Saturday, 08 March 2008, 12:16 PM +0100): I’ve read the discussion and I really agree with Matthew first answer (more below ) : Some more information here: ZFI and Zend_Form do pre-filtering in order to ensure that you can perform validations. For example, spurious spaces at the beginning or end of input should not be counted against the string length; when validating a phone number, there's no need to validate anything other than the digits (this prevents the need for complex regexen to check for all potential phone number formats); content that should not contain HTML may still be valid... so long as you strip the tags first. Escaping is another operation entirely. ZFI does escaping, but ZFI's primary use case is with models -- pulling in data and then escaping it for your model. Zend_Form does escaping already... when rendering. I can see the value of a postfilter for when you associate a Zend_Form with a model. Right now, this is possible in a couple of ways: * Load a new set of filters into your elements after validation, and then pull your values. * Create a filter chain in your model (using Zend_Filter), and pass the data through that. This is probably the better place to do so, as you then know that the filtering is specific to your model. I'll consider a postfilter post-1.5.0 GA release when I start looking at associating forms with models. Matthew Weier O'Phinney-3 wrote: Validation merely makes sure that the submitted data passes certain rules. Filtering is for output -- to a database, to the screen, whatever. You validate unfiltered data, and then filter it for your output stream. Another use for filtering is normalization -- taking input and modifying it to fit a 'normal' specification. An example of this is taking a phone number -- (800) 555-1212 -- and normalizing it for your database -- 8885551212. You will often take a normalized value and filter it again for display -- 800.555.1212. Let's look at this: If I have a filter, StripTags, and then a validator, NoTags, and run the data through the filter prior to validating what's the point of the validation then? you've already ensured that it will pass no matter what.. but now when you return the data to the user, it looks unfamiliar to them. Better is to check for tags in the first place, and let the user know they aren't allowed... or, allow them, but strip them out prior to storing or displaying the information (to prevent XSS attacks, for example). Then Matthew changed it to pre-filter base on what I've been done in ZFI For those who are interested: The idea is to allow some normalization of data prior to sending it to validation. The example given me was one of a username: * Allow only 3-16 characters and you get ' mweierophinneyzend ' as input... it would fail validation, but likely shouldn't have. If the input were run through StringTrim first, it would pass. Basically, such normalization ensures that the data is *ready* for validation. It looks to me that only StringTrim fit the use case of pre-filtering data. And I’m style convinced that post filtering is a better approaches. :) -- Laurent Melmoux Annecy, France Amr Mostafa a écrit : Hi Laurent, While I don't have the answer to your question specifically, I know that Zend_Form used to validate before filtering like you are suggesting. But that was modified per this discussion: http://www.nabble.com/Zend_Form_Element-validation-bug-tt15589810s16154.html As a side note, I've done something very similar to the use case you describe, and didn't run into this problem. The only difference I had was that the filter converts the given date to a Zend_Date instance. Which then runs through Zend_Validate_Date and it's has been working fine. Think I got lucky there and I've even noticed it :) Back to the discussion linked above, in one post I can tell that Matthew acknowledged the important of a pre/postFilter. Best Regards, - Amr On Sat, Mar 8, 2008 at 11:26 AM, Laurent Melmoux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Matthew and every body, First a use case: On an i18n application the user can chose is preferred date format for display and input. Let's say 'dd/MM/'. I n the backend I will need a validator to validate the date format and a filter to convert the date to a Mysql format '-MM-dd'. But here the validation against 'dd/MM/' won't work because the date will be filtered before validation. Well, an easy work around will be to validate against the '-MM-dd' format but it sound not very clean and I could not use an error message saying the right format to use. So I'm wondering if data should be filtered prior to validation. Is there some security concern? While I see some advantage to filter data, like
Re: [fw-general] Reply to mailing list
There's a good chance you're not making through the spam filter. I haven't had a chance to log in and clean it up for a couple of weeks, but I'll get to it today or over the weekend. If you're there, I'll whitelist your email so it won't happen again. ,Wil Thank you, I'm surprised that the mailing list received this E-mail. -- Isaak Malik Web Developer
