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.knplabs.com/en> 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
