Le 01/10/2012 16:54, David Buchmann a écrit :
be that as it may .. how do we address the issue of wanting to be able to match
different routes for different users?
f.e. i want to be able to have a publish/unpublish flag for pages .. or a
publish date. of course this would not apply to admins, who also need to be
abel to view unpublished pages. this is where i would naturally want to add
some logic to the routing to determine if the user has access to the page or
not.
as things are now, i would need to handle this inside the controller i guess.
which means that incase the user does not have rights, i throw a 404.
for the cmf we could also handle access control in the route enhancement
step (where we determine the controller based on content and such). ah,
but that is still inside the routing step.
however this diminishes the flexibility.
what if in case the user does not have access rights to view the page i want
them to then to load some alternative page, rather than some generic 404 page?
then my controller needs to have logic to dispatch to the correct route, which
is quite a mess imho.
would it be so wrong to have a custom 404 handler that checks if a page
could be created here by this user and then changes the response to the
page creation dialog?
so it seems we do not offer anything for this use case or the use case Thomas
mentioned?
i really think that with uses cases like CMS, shops, CRM etc dynamic routing will become
a critical topic to address and so i think we need to be wiling to invest time to make
such use cases work, rather than "simplifying" by making them impossible in a
clean way.
i agree we need to have a good way to do this, just am not yet sure if
its a documentation issue or if we need some feature. why can't routing
exist and security service both exist before the routing process is
terminated? i see that the security depends on having routing, but that
does not mean it should be impossible to instantiate security before
routing a request is terminated.
(though there is a potential for endless loops here, when the security
error would trigger a route generation that triggers the same security
error again...)
cheers,david
the issue is not the instantiation (both are instantiated when
initializing the kernel.request listeners) but the order in which they
are triggered:
- the router is not fully working until it has been initialized from the
request (done in the RouterListener)
- the security token (needed to check permissions) is not available
until the firewall has been triggered
- the security system needs a working router when being called, to be
able to use route names for the check path and the login path (to
redirect you to the right url)
in 2.0, the triggering of the router was split in 2: the first part of
the initialization (setting the host name, the port, etc...) before the
firewall and the matching itself after the firewall.
But this was causing many issues because an error thrown by the firewall
would result in an error page rendered by an half-working router.
--
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 symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
