Something comes to my mind about input validation. PHP 5.2 now contains
the filtering functions, so even when symfony is going to roll its own,
I would like it to be as compatible with the filter extension as
possible.
What I'm thinkg of is a filtering plugin. This plugin offers a
(1) Compatibility class for PHP < 5.2, and a
(2) Wrapper class for PHP5.2 filter extension.
Both shares the same set of API, but (1) offers only basic
functionality.
The startup config decides whether functions in (1) or (2) is to be
registered to the sfAction / sfComponent classes. Then we can use, for
example
$this->filterVar(),
$this->filterInt(),
$this->filterUrl(), ...
If $this->filterUrl($this->getRequestParameter('foo')) looks too clumsy
maybe
$this->filterRequestVar() can be added, or even reigster the functions
to sfRequest.
On Dec 17, 11:46 pm, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As for escaping the following stuff seems to work long as you work
> inside a single context (your template only outputs variables as html
> content ..):http://blog.calmtech.co.uk/symfony/xss.php
>
> However I envision it quickly becomes a hassle when you mix html and
> javascript outputting. As such the helpers seem like a better approach
> although I think there should be a way to easily also echo in the same
> step, to really make this easy
> todo:http://www.symfony-project.com/api/symfony/helper/EscapingHelper.html
>
> I do not really think I have the perfect solution myself just yet, but I
> have a few ideas in my old framework that seem to be worthwhile to
> me:http://svn.oss.backendmedia.com/modules/module_common.phps
>
> Have a look at the write() method. As you can see its far from mature,
> but I think its important to make the code needed to output escaped
> variables as easily and concise as possible. Essentially you define a
> default escape mode, but you can easily overwrite it with a single
> parameter.
>
> There is another thing in this class that I think is a good idea to
> have. The idea is to ensure that modules only receive previously defined
> variables and only pass previously defined variables to the template. I
> would only run these checks when in dev mode and not when in prod mode.
> This both centralizes the security, but also serves as a low level
> documentation:http://svn.oss.backendmedia.com/modules/installer/installer.phps
>
> Look at the $param_rules and $templates properties. They define the
> allowed parameters coming into the module or going out to templates.
>
> The validate() and getRenderedTemplate() methods respectively are
> responsible for doing these checks.
>
> Like I said, I do not claim that these implementations are mature, but I
> think they are worthwhile food for though. In relation to this I also
> want to mention the some what irritating situation that variables are
> only passed to templates if they are set at runtime and not as a
> property of the action class. I think this topic should also be
> revisited, or at least configurable.
>
> regards,
> Lukas
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
