Ok, well, that issue in particular is now a ticket (though I either can't
add labels or i foobar'd it): https://github.com/symfony/symfony/issues/917

What about these three guys? Should I open a ticket for the first one?

* AccessDeniedException seems to cause a 500 error - I'm not sure if it used
to do a 403 or how that works.

* The anonymous user isn't an object - I wonder if this is because user
objects must have encoders and that would cause some problems?

* How the entry point is determined when you have multiple authentication
mechanisms?


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 Thu, May 12, 2011 at 1:06 AM, Christophe COEVOET <[email protected]> wrote:

>  Le 12/05/2011 07:04, Johannes Schmitt a écrit :
>
> I think we changed the ordering of priorities at some point, and the
> listener was simply forgotten to be updated. It should run at the earliest
> possible point.
>
> Kind regards,
> Johannes
>
>
>  On Thu, May 12, 2011 at 1:30 AM, Christophe COEVOET <[email protected]>wrote:
>
>> Le 12/05/2011 00:19, ryan weaver a écrit :
>>
>>  * Due to the onCoreRequest ordering, you'll hit a 404 page before the
>>> firewall forces authentication. How *big* of a deal is this? I'm not used to
>>> this behavior, but the authentication listeners rely on being *after* the
>>> onCoreRequest listener of the framework (for the session)
>>>
>>  A solution could be to split the logic in 2 listeners. One responsible to
>> initialize the session, and the other responsible to do the routing. And so
>> the firewall could be registered between them.
>>
>> Thus, registering the first one with a positive priority will ensure it is
>> called before any listeners registered the default way. This would make the
>> session available to the other onCoreRequest listeners without relying on
>> FrameworkBundle being registered first in the kernel (as the order should
>> not matter according to the decision made when refactoring the bundle
>> management).
>>
>>   I also thought that it was a left-over of the priority change, but the
> security ContextListener relies on the session so it needs to run after it
> is initialized.
>
> --
> Christophe | Stof
>
>  --
> 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

Reply via email to