Skip to content
This repository has been archived by the owner on Jul 3, 2020. It is now read-only.

append_previous_uri not compatible with ZfcUser #252

Open
tad3j opened this issue Jun 21, 2014 · 5 comments
Open

append_previous_uri not compatible with ZfcUser #252

tad3j opened this issue Jun 21, 2014 · 5 comments

Comments

@tad3j
Copy link

tad3j commented Jun 21, 2014

Before I implemented ZfcRbac I was redirecting user after login via ZfcUser "use_redirect_parameter_if_present", but I somehow can't get it working now. If I have that option enabled in ZfcUser and ZfcRbac at the same time, I get an error because the 1st one expects ROUTE to be passed as "redirectTo" parameter and the 2nd one is passing URL. Is there a way around it or should that get changed on one or the other side to keep them compatible?

Edit: I think that using URL for redirect is more flexible than using route only, so I'll open an issue on ZfcUSer instead: ZF-Commons/ZfcUser#473

@tad3j
Copy link
Author

tad3j commented Oct 1, 2014

Looks like for ZfcUser module they've decided to go ahead with routes instead of URI (https://github.com/ZF-Commons/ZfcUser/pull/487/files), saying that it's insecure using the URI, so I was wondering if there is any chance to change this module to work with ZfcUser? I guess we could replace URI with route redirect, or maybe use both versions? I guess for using both an additional "else if" could be added for "append_previous_route" option here:

if ($this->options->getAppendPreviousUri()) {

What do you guys think?

@bakura10
Copy link
Member

bakura10 commented Oct 1, 2014

Hi. I'm not sure to understand. The append_previous_uri cannot be used for routes, as it is a copy of the route that was not accessible. When we retrieve the URL that was tried to be accessed, we definitely cannot transform an URI to a route. And even if we could, we would loose some important parameters like query parameters.

Or did I misunderstood something...

@tad3j
Copy link
Author

tad3j commented Oct 1, 2014

No, I think you are right, I haven't thought about that. Was just brainstorming on how to fix this compatibility issue, but looks like ZfcUser should then use URI as well, in order to work with ZfcRbac I guess.

@intellent
Copy link

Sorry to bring this up, again. But imho the append_previous_uri feature doesn’t make much sense without support for zfc-user’s use_redirect_parameter_if_present setting. Wasn’t this the reason this was introduced in the first place?

Is there any way to solve this? E.g. with another option like append_previous_route (ignoring query params, of course)? Is it possible for zfc-rbac to fetch the inaccessible route, if you have Controller guards in place?

@Rud5G
Copy link

Rud5G commented Nov 12, 2016

Its possible to override the ZfcUser RedirectCallbackFactory in the config of your module

    'service_manager' => array(
        'factories' => array(
            'zfcuser_redirect_callback' => 'Application\Factory\RedirectCallbackFactory',
        ),
    ),

which will let you insert your own RedirectCallback in the default ZfcUser\Controller\UserController.
in the RedirectCallback, you can write a function to match urls to a RouteMatch, and if avaibable redirect to the url of that matched route.

        $request = new Request();
        $request->setMethod(Request::METHOD_GET);
        $request->setUri($redirect);

        $match = $this->router->match($request);
        if (!$match) {
            return $redirect;
        }
    protected function getUrlFromRouteOrMatch($routeOrRouteMatch)
    {
        if ($routeOrRouteMatch instanceof RouteMatch) {
            $params = $routeOrRouteMatch->getParams();
            $routeName = $routeOrRouteMatch->getMatchedRouteName();
        } else {
            $params = [];
            $routeName = $routeOrRouteMatch;
        }

        return $this->router->assemble(
            $params,
            ['name' => $routeName]
        );
    }

dont forget to set the

'previous_uri_query_key' => 'redirect'

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants