My thought is that security is something we should provide an easy mechanism to implement. However writing a new bundle to get rid of multiple firewalls seems like a bad approach. Documentation! To be clear, our documentation should show a user a quick way to get running without covering the nitty-gritty of multiple firewalls. Multiple firewall support should be covered later. A SecurityLightBundle introduces more code that needs to be tested, and maintained. If a developer implements SecurityLightBundle and needs SecurityBundle at a later date it requires refactoring. Refactoring that will likely raise more questions, and require support.
I am EXTREMELY for simplistic implementations inside of documentation, or even as published examples. An application walkthrough (similar to Askeet or Jobeet) would be great to show the evolution of an application from a single firewall to multiple firewalls. I personally find that examples of patterns more useful after i've seen them used once. (Not trying to be cruel Lucas. But you did describe an issue; "Authentication in Symfony 2 can be complex, and developers will likely be confused if they dove in now.") On Apr 19, 2011, at 5:34 PM, ryan weaver wrote: > I'm easily persuaded - we'll have to make changes to how the docs are written > anyways, so we might as well start there. If an need still exists for a Light > bundle, then we're still free to make it. > > Having a group of "recipes" for common situations (caefer brought this up on > a blog post) seems like it'll accomplish the same plug-and-play functionality. > > As far as documentation, I've so far stayed away from security both to let it > mature and because there's a lot of other documentation to be written. I > suppose it's time now for one or a few of us to take it on and restructure it > per Fabien's description. > > Ryan Weaver > US Office Head & Trainer - KnpLabs - Nashville, TN > http://www.knplabs.com > http://www.thatsquality.com > Twitter: @weaverryan > > > On Tue, Apr 19, 2011 at 4:27 PM, Johannes Schmitt <schmitt...@gmail.com> > wrote: > I think time would be better spent by creating typical default configurations > for different use cases. Having an entirely different way to set things up is > a bad idea imo. > > Johannes > > > > On Tue, Apr 19, 2011 at 11:11 PM, Lukas Kahwe Smith <m...@pooteeweet.org> > wrote: > On 19.04.2011, at 22:50, Fabien Potencier > <fabien.potenc...@symfony-project.com> wrote: > > > > > On 4/19/11 10:27 PM, Lukas Kahwe Smith wrote: > >> On 19.04.2011, at 21:05, Johannes Schmitt<schmitt...@gmail.com> wrote: > >> > >>> Since I wasn't present at this talk, could you explain the reasoning > >>> behind having a "light" bundle? What's its purpose? > >> > >> he spend a fair bit of time explaining how multiple firewalls work. though > >> its pretty clear most applications will never need this. however when you > >> start out you do not even expect this feature as no other php framework i > >> know provides capabilities like this. > > > > Sounds like a problem in the talk and probably the current documentation as > > well. As we are "proud" of the flexibility of our solution, we try to > > explain everything. That's probably a bad approach. We should first teach > > people how to do simple things, things they will need 90% of the time and > > move everything else to cookbook tutorials. And things that you need 90% > > of the time are really easy to achieve as this is just about configuration. > > the problem i see is that the multiple firewall concept seems to always be > misunderstood initially. to me it was kind of this unsolveable riddle that > kept my head spinning as i was trying to grasp things. during the talk i > realized that stefan went through the same experience. and i also have spend > countless hours explaining this to users on irc. > > > > >> this in turn means that in the beginning you think that you need to use > >> one firewall for each auth method. since afterall why else would here be > >> multiple firewalls? > >> > >> same with the userbundle. it confuses uses what and why they need to set > >> the firewall name so that we can authenticate after password recovery. > >> > >> another classic is the redirect loop on the login page because anonymous > >> access hasnt been granted. > >> > >> but like i said this light bundle should extend the SecurityBundle and > >> would only contain a DI extension for configuration. there would be no > >> additional runtime logic. > > > > The problems you mention here should be addressed by the documentation > > (see above). We can also tweak the "default" behavior where it makes > > sense. But I fail to see what a light bundle will provide. > > i think its problematic to default to unsecure certain urls. especially since > there could be use cases where you dont want this. > > so the idea would be that by having this separate bundle that implements the > "dumb" syntax we can optimize the syntax for both cases without causing too > many edge cases and making tight validation impossible. > > regards > Lukas > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
