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 <[email protected]>wrote: > On 19.04.2011, at 22:50, Fabien Potencier < > [email protected]> wrote: > > > > > On 4/19/11 10:27 PM, Lukas Kahwe Smith wrote: > >> On 19.04.2011, at 21:05, Johannes Schmitt<[email protected]> 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 [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 > -- 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 [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
