bar.js won't load if current URL 404s due to apache restrictions

[adrianbj]

Version: 2.7.3

Bug Description

If you visit a URL that is blocked by apache (ie before it hits PHP), eg:
http://pwtest.test/hjk'k

when there is an Apache rule like:

 RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$"

preventing access to a URL with a '.

you get the following error:
GET http://pwtest.test/bla'h/?_tracy_bar=js&v=2.7.3&XDEBUG_SESSION_STOP=1 net::ERR_ABORTED 404 (Page Not Found)

Possible Solution

I am not sure the relevance of using <?= Helpers::escapeHtml($baseUrl) ?> here:

tracy/src/Tracy/Bar/assets/loader.phtml

Line 22 in f1d0d25

<script src="<?= Helpers::escapeHtml($baseUrl) ?>_tracy_bar=<?= urlencode("content.$contentId") ?>&amp;XDEBUG_SESSION_STOP=1" data-id="<?= Helpers::escapeHtml($contentId) ?>"<?= $asyncAttr, $nonceAttr ?>></script>

Is there a reason the full URL to the page is needed here? If the path is changed to the root of the site, eg: http://pwtest.test/?_tracy_bar=js&v=2.7.3&XDEBUG_SESSION_STOP=1 then it loads as expected, but perhaps there is a need for the full url to the current page that I am not aware of.

Thanks.

[dg]

Is there a reason the full URL to the page is needed here?

Yes, it is related to #216 and fixed by b0845f5

[adrianbj]

Thanks @dg for the explanation. Can you think of a way to accommodate that as well as ensuring Tracy can still load in the scenario described above, or should I just close this because it's something we just need to live with?

[dg]

I do not understand why you can visit http://pwtest.test/bla'h but not http://pwtest.test/bla'h/?_tracy_bar=js&v=2.7.3&XDEBUG_SESSION_STOP=1

[adrianbj]

It's possible to visit both. Here is the htaccess file (https://github.com/processwire/processwire/blob/master/htaccess.txt) that contains that rule noted in the OP.

I misspoke above when I said it prevents complete access to PHP, but it does prevent http://pwtest.test/bla'h/?_tracy_bar=js&v=2.7.3&XDEBUG_SESSION_STOP=1 from loading Tracy:

http://pwtest.test/blah/ loads Tracy fine (even though that page still doesn't exist. Of course thes request is making use of mod_rewrite as you can see in the htaccess I just linked to: RewriteRule ^(.*)$ index.php?it=$1 [L,QSA]

If I remove that RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$" and try to visit: http://pwtest.test/bla'h/ then there is no problem and Tracy loads properly.

Does that explain it better?

Thanks.

[dg]

Oh, so problem is that Apache returns 404. So solution is to add http_response_code(200) before each header('Content-Type.... in Bar::dispatchAssets(). Can you test it?

[milo]

I think that point is, that Tracy GET is not even executed, because the Apache denied access before a rewrite rule to index.php is done.

[adrianbj]

@dg - that doesn't help. I think what @milo is saying here is the issue.

[dg]

If Tracy appears on the url http://pwtest.test/bla'h, I don't understand why it won't appear on http://pwtest.test/bla'h?xxx. Are GET parameters passed correctly? Who sets HTTP code to 404?

[adrianbj]

If Tracy appears on the url http://pwtest.test/bla'h

Tracy doesn't appear at that URL - it gives the errors I showed here: #407 (comment)

Tracy does appear at: http://pwtest.test/blah (note the missing apostrophe), because the htaccess rule isn't getting invoked and isn't preventing the rewrite at the bottom of the file to index.php?it=

Here are some interesting results - note the graphics show the request for the URL itself and then the URL with the tracy get params.

http://pwtest.test/blah (no apostrophe)

http://pwtest.test/bla'h (with apostrophe)

So you can see that the request which includes the _tracy_bar doesn't 404 when the URL has no apostrophe. So I think it comes down to whether apache or PHP is throwing the 404.

Do those help explain things?

[dg]

When I said that Tracy appears I meant that Tracy is enabled (and generates some HTML output). So I don't understand why is Tracy enabled on http://pwtest.test/bla'h but not on http://pwtest.test/bla'h?xxx. Maybe GET parameters aren't passed correctly to PHP. Or maybe there is something in source code that prevents Tracy to do its work.

[adrianbj]

Sorry, I must be being dumb here, but I don't see that Tracy is generating any HTML output on http://pwtest.test/bla'h - what output are you referring to?

[dg]

Something like <!-- Tracy Debug Bar --> <script src="bla'h?_tracybar=....></script>

[adrianbj]

Well, I do get this when viewing http://pwtest.test/bla'h?_tracy_bar=js&v=2.7.3&XDEBUG_SESSION_STOP=1 directly:

[dg]

So try to dump $_GET parameters on this page.

[adrianbj]

So try to dump $_GET parameters on this page.

Returns an empty array

[dg]

So it is misconfiguration of Apache. Probably somewhere is RewriteRule without QSA.

[adrianbj]

Ok, so I went looking and it turns out it's this:

https://github.com/processwire/processwire/blob/51629cdd5f381d3881133baf83e1bd2d9306f867/htaccess.txt#L73

which prevents the query string parameters from making it to Processwire's 404 handler. Seems like it might be possible to implement a solution in ProcessWire that makes use of $_SERVER['REDIRECT_QUERY_STRING'] to get those GET params loaded.

Sorry for the time you spent on this today - it just seemed like a weird way to load Tracy's JS file, I wanted to make sure something couldn't be done at this end.