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
