Closed rvanginneken closed 4 years ago
@acrobat Did I get everything?
The reason for this is that targetPath is filled by the Request's function "getUri"
Isn't that the root issue you should try to fix?
@greg0ire Well we've been at it for quite a while and we haven't found any other viable solution. Part of the problem is that the router is aware of the "relativePath" but the request isn't. By making the Request (or SiteRequest in this case) aware of the relativePath, it will be added twice on some occassions (router will build on the request's base, which already has the relativatPath added).
This fix works for us and like I said, I'm willing to put in a PR. We don't currently have the time for debugging and find a better solution. Also I think we miss the knowledge of the internals to do this.
@greg0ire I'm not really sure what to do with this gif :)
I mean you can do a PR with this workaround :P
I'm starting to have real doubts about this solution... I think we should get other opinions from @sonata-project/contributors that might know how to fix this properly before going on.
Allright I'll push a few of the changes you requested. I'm not gonna spend more time on it for now then :)
Great! I would hate your PR to be refused after you work too hard on it.
By making the Request (or SiteRequest in this case) aware of the relativePath, it will be added twice on some occassions (router will build on the request's base, which already has the relativatPath added).
Sounds like a thorough test suite would help here.
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Environment
Sonata packages
Symfony packages
PHP version
Subject
In our project, we're working multilanguage by using the "host_with_path" setting. We had to add another firewall layer for our "regular" users and here we were met with a problem: When surfing to a page behind the firewall, the user is automatically redirected to the login page. After a succesful login, he should be redirected back to the page he wanted to go. We noticed however, that in our setup the user would be redirected to the homepage.
The reason for this is that targetPath is filled by the Request's function "getUri". This function is not aware of our "sites" and their "relative paths". So it would redirect the user to the targetPath without the relative path, which page does not exist, redirecting it again to the homepage. For example, when our initial target was localhost/nl/payment, getUri will return localhost/payment.
We've built a fix for this in our project, which I'm willing to make a PR for, but I prefer to first hear your feedback. Our fix overrides the "security.exception_listener" and all it changes is the targetPath saved to the session.
On a sidenote: we've noticed earlier on some problem with relative paths in the admin environment. For example: Using "show" on localhost/nl/admin/sonata/page-page/49/edit would redirect the page to localhost/nl/nl/PAGE-SLUG (note the doube /nl). But because this was of minor concern at the time, we solved that one by forcing only access to the domain without relative path through the .htaccess.