We have seen the following behaviour on a site:
1. https://site.com/index.php/user/login <-- Redirects correctly to https://site.com/user/login
2. https://site.com/%69ndex.php/user/login <-- Redirects to https://site.com/index.php/user/login
With scenario 2 above, the index.php is carried around all future parts of the site you click on.
This is getting around rules we have to lock the admin UI down to certain IPs etc. I'm not sure I could make a rule that would cater for all possibilities (keeping in mind I'm not an expert at that sort of thing)
Is this expected behaviour? Would there be example htaccess rules that I could configure to do proper redirects?
Stragely - Happens a lot more in Firefox than Chrome, and is slightly inconsistent. Maybe due to caching?
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | clean-urls-redirect.png | 14.26 KB | danielveza |
| #4 | clean-urls-encoding-3067170-4.patch | 639 bytes | danielveza |
Comments
Comment #2
cilefen commentedComment #3
danielvezaDone a bit more digging on this. In the contrib module redirect - I've set the "Enforce clean and canonical URLs" setting. During this and testing it was raised that this is being bypassed when index.php is encoded.
I'm not 100% sure if this should be fixed in the redirect module or Core but personally it seems that this is a core bug with the isCleanUrl function.
I've added a small patch to fix this. I'd be interested in hearing core peoples opinions before taking it any further.
Comment #4
danielvezaComment #14
smustgrave commentedThis came up as the daily BSI target
Just tested on a 11.4 project and can confirm the issue still exists.
Can we update the summary to the standard template.
Will also need test coverage. I don't see anything directly testing RequestHelper helper but maybe a unit or kernel test would be best.