On 4/19/11 11: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.
I think each recipe should answer a typical question. That's how I
introduced the security component at Symfony Day:
http://www.slideshare.net/fabpot/the-state-of-symfony2-symfonyday-2010
Fabien
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> wrote:
On 19.04.2011, at 22:50, Fabien Potencier
<[email protected]
<mailto:[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] <mailto:[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
<http://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] <mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:symfony-devs%[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 <http://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]
<mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:symfony-devs%[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
--
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
