remove / from the beginning and ending of query string

[pradpnayak]

Overview

When a query string has '/' in the beginning, it fails with ''You do not have permission to access this content.' error eg when you have q=/civicrm/contribute/transact/ it generates $args after explode as

Array
(
    [0] => 
    [1] => civicrm
    [2] => contribute
    [3] => transact
)

Which causes permission denied because of check in check_permission() function.

[christianwach]

@pradpnayak Thanks for this - it seems like a reasonable sanity check. It would be useful if you explain (or show) where such malformed URLs come from. Thanks.

[pradpnayak]

we have a nginx setup with rule try_files $uri $uri/ /index.php?q=$uri&$args; and this causes '/' at the beginning of the url

[pradpnayak]

retest this please

[christianwach]

@pradpnayak Okay ,so please forgive my relative lack of nginx knowledge, but...

1. Doesn't this simply mean that your rule is wrong?
2. Why are you trying to build old-style (non-clean) URLs?
3. Why not ditch the rule and use clean URLs instead?

[mlutfy]

@pradpnayak Is it a bug that appeared recently? Since which version? I'm still on 5.25, but haven't had issues with nginx.

We use:

  try_files $uri $uri/ /index.php?$args;

[pradpnayak]

I will recheck my ngnix config

[christianwach]

@pradpnayak FWIW, I think this PR should be re-opened - as I said, the sanity check is a reasonable one and I'm very much in favour of sanity checks. My questions were intended to understand how malformed URLs could occur... and, of course, there are many possible sources of malformed URLs... which is why we have sanity checks!

[christianwach]

@pradpnayak Thanks, I'll discuss this with @kcristiano tomorrow and decide what to do. In the meantime, it's a good thing that you're reviewing your nginx rules.

[pradpnayak]

This happens when you have $_REQUEST['q'] or $_GET['q'] set, incase when your nginx rule has
try_files $uri $uri/ /index.php?q=$uri&$args;

but works when you set

try_files $uri $uri/ /index.php?$args;

[stesi561]

Just further to the above that rewrite rule is what is present in the Official Nginx recipe for wordpress -> https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/ however I do see in our config we are doing this slightly differently with a comment about some modules not liking a trailing slash.

[eileenmcnaughton]

Something has changed - I think maybe on the wordpress side not the civi side but I have is_home() failing with a long-standing nginx rewrite rule

As with @pradpnayak's example above the 'q=' in the rewrite rule is causing an issue