You must define the route as far as I know.
Did you try it already?

Regards.

2011/4/4 Christian Schaefer <cae...@gmail.com>

>
> no. and why would I?
>
> there is no controller to handle that route. instead the security
> component provides a listener that intercepts. or did that change as
> well?
>
>
> On 5 Apr., 07:14, oscar balladares <liebegr...@gmail.com> wrote:
> > Hi.
> > Did you define the route for login_check?
> >
> > #app/config/routing.yml
> >
> > _security_login:
> >     pattern:  /login
> >     defaults: { _controller: YourBundle:Security:login }
> >
> > _security_check:
> >     pattern:  /login_check
> >
> > _security_logout:
> >     pattern:  /logout
> >
> > 2011/4/4 Dennis Jacobfeuerborn <djacobfeuerb...@gmail.com>
> >
> >
> >
> >
> >
> >
> >
> > > On Monday, April 4, 2011 11:10:26 PM UTC+2, Christophe COEVOET wrote:
> >
> > >>  Le 04/04/2011 22:44, Dennis Jacobfeuerborn a écrit :
> >
> > >> On Monday, April 4, 2011 10:31:30 PM UTC+2, Christophe COEVOET wrote:
> >
> > >>>  Le 04/04/2011 22:27, Dennis Jacobfeuerborn a écrit :
> >
> > >>> I just upgraded from PR8 to the current git state but this broke the
> > >>> security stuff. Apparently the security component no longer handles
> the
> > >>> _security_check route?
> >
> > >>> Unable to find the controller for path "/login_check". Maybe you
> forgot
> > >>> to add the matching route in your routing configuration?
> >
> > >>> You need to define a controller as the listener intercept the request
> *
> > >>> only* when the credentials are right. If they are wrong the request
> is
> > >>> not intercepted and then goes to the controller (this was still the
> case
> > >>> before).
> >
> > >>>  I'm not sure I understand. How can the framework even determine if
> the
> > >> credentials are right if it doesn't intercept the /login_check call?
> >
> > >> If the credentials are right, the listener returns a Response, so the
> > >> request stops here and the controller is never called. If they are
> wrong,
> > >> the listener does not return a response so the request continues to
> the
> > >> controller
> >
> > > I'm still not sure how this relates to the problem. Given that this
> error
> > > doesn't change with right or wrong credentials I'm not sure what I'm
> > > supposed to do differently compared to PR8?
> > > To phrase this differently: What changes to the code/routing/security
> are
> > > required to make an app that works fine in PR8 also work fine in PR10?
> >
> > > Regards,
> > >   Dennis
> >
> > >  --
> > > 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 users" group.
> > > To post to this group, send email to symfony-users@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > symfony-users+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > >http://groups.google.com/group/symfony-users?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 users" group.
> To post to this group, send email to symfony-users@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-users+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-users?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 users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en

Reply via email to