All, I agree with Francois that we should not force the config options. Though I think that we should enable security features by default. I like the ability to change the settings via the symfony cli (we can expand on this and have a scriptable application creation process with plugins etc). I think we should just elaborate on csrf/xss protections more in the book and my first project tutorial.
- Dustin On 3/31/08 8:47 AM, "Francois Zaninotto" <[EMAIL PROTECTED]> wrote: > Given the 'convention over configuration' mantra, I'm not sure forcing two > config options at creation time is a good idea either. > > Documentationwise, that would imply explaining the security caveats of every > web app even in a novice symfony tutorial. There is a time to do this, in the > learning process of professional application development, but it is probably > not when you give the framework a try. > > So I'm more in favor of an "unsecure" default, but with a new doc chapter > explaining all the security risks and all the bad things that could happen, > unless... You change two settings in the settings.yml. > > My 2c, > > François > > 2008/3/31, Fabien POTENCIER <[EMAIL PROTECTED]>: >> >> Lucas Stephanou wrote: >>> > I think that security options must be on be default, educate developers >>> > is lovely but when creating web applications isn't right place to do >>> that. >>> > So I do vote to both protection on and if someone want to disable( >>> > knowing what he was doing) do it explicit. >>> > The name for options are ok. >> >> >> There is no default. When you create an application, you must provide >> those 2 options. >> >> Fabien >> >> >>> > >>> > On Mon, Mar 31, 2008 at 10:11 AM, Fabien POTENCIER >>> > <[EMAIL PROTECTED] >> >>> > <mailto:[EMAIL PROTECTED]>> wrote: >>> > >>> > >>> > I will post a blog post about security when we will release the >>> beta3. >>> > >>> > Short story: >>> > >>> > People need to be aware of what kind of things are done automatically >>> > for them. If not, they won't understand the principles behind the >>> CSRF >>> > protection and then, they won't understand why you can't put a form >>> with >>> > CSRF protection in the cache ;) The same goes for CSS protection >>> (output >>> > escaping). >>> > >>> > In beta3, the generate:app task will have new mandatory option(s) to >>> > configure the security level of the new application. It will force >>> users >>> > to think about the security and what to enable/disable by default. >>> > >>> > And here is a question for all of you. How to name this/these new >>> > options. Here is my proposition: >>> > >>> > 2 options, one for XSS and one for CSRF: >>> > >>> > --xss-protection=on / off / both >>> > >>> > --csrf-protection=on / off >>> > >>> > Let's start the discussion ;) >>> > >>> > Fabien >>> > >>> > -- >>> > Fabien Potencier >>> > Sensio CEO - symfony lead developer >> >>> > sensiolabs.com <http://sensiolabs.com> <http://sensiolabs.com> | >>> symfony-project.com <http://symfony-project.com> >>> > <http://symfony-project.com> | aide-de-camp.org >>> <http://aide-de-camp.org> >>> > <http://aide-de-camp.org> >> >>> > Tél: +33 1 40 99 80 80 >>> > >>> > >>> > Ian P. Christian wrote: >>>> > > Not that I'm overly bothered.... but... >>>> > > >>>> > > Why has CSRF been disabled by default? >>>> > > >>>> > > Kind Regards, >>>> > > >>>> > > Ian >>>> > > >>>>> > > > >>>> > > >>>> > > >>> > >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > Lucas Stephanou >>>> > > >> >> >> >> >> >> >> >> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
