Problem/Motivation
I set an allowed route to /user/ and didn't set any URL parameters. Once logged in, it gave me a 403 error because the url of the page displayed is /user/42?check_logged_in=1 (...with a query string).
Steps to reproduce
- Install with composer and enable version 2.0.0-beta1 on Drupal 10
- Add a new restricted route with these parameters
- Route name or path: /user/
- Request methods: GET, POST
- URL parameters: Leave it empty
- Ips: Enter your ip
- Operation: Allow access
- Check Enabled
- In your browser, open a new private page and go to /user/login of your site. You should see it.
- Log in
- You should have a 403 error if there's a quey string in the url.
- Otherwise, go to /admin/people and edit any user. The url should be /user/%/edit?destination=/admin/people and you should have a 403 error.
Proposed resolution
Logically, if I don't set any URL parameters, it should accept any query string passed to the URL. And looking at the code I think that's what it was supposed to do, but a logic error broke the condition.
I believe the problem comes from the condition present on line 256 of RestrictIpService.php : if (!$params && !$query_string) {
In fact, it could be if (!$params || ($params && !$query_string)) { to check if URL parameters is not set, and otherwise if it's the case, to check if a query string is not passed to the page.
In addition, none of this code has test coverage, so that should be added.
Remaining tasks
Review the submitted merge request.
| Comment | File | Size | Author |
|---|
Issue fork restrict_route_by_ip-3405569
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
franckylfs commentedComment #3
solideogloria commentedif (!$params || !$query_string) {is exactly the same asif (!$params || ($params && !$query_string)) {, so that would be shorter if it works.Comment #5
solideogloria commentedPlease review the merge request. It works the same way you described, and it fixes the issue for me.
Comment #6
solideogloria commentedMarking this issue as Major, since it would prevent most potential uses of this module altogether.
Comment #7
franckylfs commentedThanks! I approve, but I think I can't do it on git.drupalcode.org. Sorry :(
Comment #8
solideogloria commentedA maintainer has to do that part.
Comment #9
solideogloria commentedWorking on creating tests.
Comment #10
solideogloria commentedThe
requestAffected()function didn't have any tests for it at all! I added test coverage for the entire function, not just for the changed functionality.It's a good thing I spent time last week reading about how phpspec/prophecy works, because the module's tests use it a lot.
Comment #11
solideogloria commentedComment #12
solideogloria commentedComment #13
solideogloria commentedAdding as a related issue, since I fixed its failing phpunit test here.
Comment #14
solideogloria commentedComment #15
solideogloria commentedShorter title.
Comment #16
solideogloria commentedComment #17
solideogloria commentedStill waiting on review.
Comment #18
tyfoo commentedI just bumped into this issue as well. At least for me, leaving the params option empty should mean that we don't care about matching the query string.
So instead of
We could just have
What do you think?
We are also trying to restrict the
/user/route, but URLs like/user/1/edit?destination=/admin/peoplearen't working correctly because of the query string.Comment #19
solideogloria commentedDid you try the patch from the MR? The MR uses
if (!$params || !$query_string) {, which should also work.Comment #20
tyfoo commentedYeah, the MR does work for my case. I wonder about the logic still, though. If a user specifies params, they probably want to make sure the request params match right?
!$params || !$query_stringwould work for cases where no params were specified, but also where params were specified but no query string is present.What do you think? I could see the argument either way, really.
Comment #21
solideogloria commentedSame. I don't have that use case personally, so I don't really know either way, to know which is better.
I think that argument makes sense, though. The tests will also need to be updated. Specifically this part, since we would be changing it to not be affected if there were no query params given but the route restriction has query params specified:
Comment #22
solideogloria commentedReview the changes now. I added more tests for more use cases.
Comment #23
solideogloria commentedThe changes here will not apply once #3524482: 2.0.x Drupal 11 compatibility. is merged. It will need to be rerolled.
However, that issue is for D11 compatibility, so please review and test it, and then we can reroll this issue.
Comment #24
solideogloria commentedComment removed. It was for another issue.
Comment #25
solideogloria commentedComment #26
very_random_man commentedI was having a problem where GET parameters were resulting in 403 when they weren't explicitly specified in the config. The MR fixes this.
Thanks!
Comment #27
solideogloria commented@very_random_man Please also review #3524482: 2.0.x Drupal 11 compatibility. if you can.