Using Tracy when 404 is triggered by .htaccess rules

[Robin S]

Hi @adrian,

If I dump something in the template file for my 404 page, or within a hook to ProcessPageView::pageNotFound, then I can see the debug bar and the dump when the requested URL is one that passes PW's rules in .htaccess, e.g.

https://mywebsite.com/this-page/does-not-exist/

But if the URL doesn't conform to PW's rules...

https://mywebsite.com/this-page/doesn't-exist/

...then I still get a 404 page that is managed by PW and the associated template file (assuming item 2 is enabled in .htaccess) but there is no debug bar or dump.

Is it possible to have the Tracy debug bar in this situation?

[adrian]

Hey @Robin S - this has bugged me for quite some and I did ask about it some time ago: https://github.com/nette/tracy/issues/407

It's basically due to htaccess's rules 16 & 17 in combination with the way the Tracy core loads itself at the base url rather than from the root url, eg, it loads:

http://mywebsite.com/doesn't-exist/?_tracy_bar=js&v=2.10.3&XDEBUG_SESSION_STOP=1

rather than:

http://mywebsite.com/?_tracy_bar=js&v=2.10.3&XDEBUG_SESSION_STOP=1

I have been playing around with fixing that. It seems like everything is working, but it's not well tested yet, so I am not sure if there will be any side effects. Would you mind also testing?

/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/loader.phtml 

//$baseUrl = $_SERVER['REQUEST_URI'] ?? '';
$baseUrl = $_SERVER['HTTP_HOST'] ?? '';

/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/bar.js

    //baseUrl = location.href.split('#')[0];
    baseUrl = location.hostname;

 

 

Can you think of any reason why this approach would be problematic? If not, I am tempted to reopen that issue and suggest these changes to @dg 

[Robin S]

Thanks for looking into this @adrian

8 hours ago, adrian said:

/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/loader.phtml 

//$baseUrl = $_SERVER['REQUEST_URI'] ?? '';
$baseUrl = $_SERVER['HTTP_HOST'] ?? '';

/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/assets/bar.js

    //baseUrl = location.href.split('#')[0];
    baseUrl = location.hostname;

This didn't work for me. $_SERVER['HTTP_HOST'] and location.hostname just give me "mywebsite.com" and without the "https://" it doesn't form a valid base for the URL.

Simply using "/" in each file worked. Or for an absolute path to the root maybe $_SERVER['HTTP_ORIGIN'] and location.origin would work. Maybe with a trailing slash added?

8 hours ago, adrian said:

Can you think of any reason why this approach would be problematic?

I'm out of my depth here, but would it be a problem when the script that is executing is not in the site root? Some cases of this might be:

1. When Tracy is being used outside of ProcessWire and the executing script is /some-directory/some-file.php rather than everything being executed from an index.php

2. When PW is installed in a subdirectory and so index.php is not in the site root

3. When PW is bootstrapped from /some-directory/some-file.php

[adrian]

19 hours ago, Robin S said:

This didn't work for me. $_SERVER['HTTP_HOST'] and location.hostname just give me "mywebsite.com" and without the "https://" it doesn't form a valid base for the URL.

That makes total sense, but for some reason it worked fine for me - weird.

Unfortunately $_SERVER['HTTP_ORIGIN'] doesn't work when the page 404s.

I did some testing with $_SERVER['PHP_SELF'] and that actually seems to work nicely, including when bootstrapping PW in a directly called .php file in the URL. However, reading back through https://github.com/nette/tracy/issues/407 I see that there is a specific reason for loading from the current URL (the linked to XDebug issue: https://github.com/nette/tracy/issues/216), so I am not sure this is actually a good idea.

Maybe it does come back to the last point I made in that issue and the loss of the GET params making it through. I am not sure anymore, and am out of steam on this at the moment. Let me know if you have any good ideas :)

[Robin S]

8 hours ago, adrian said:

Let me know if you have any good ideas ?

Seeing as this only affects the specific case when you (the developer) are debugging 404s for URLs that PW doesn't allow, maybe the solution is just to temporarily modify the PW .htaccess for the debugging session.

If you are on a local hosting or a dev site that doesn't have public access you can simply comment out rule 16A:

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

And if on a public site you could use a more permissive redirect just for your own IP address by adding this immediately after RewriteEngine On:

# Use a less restrictive redirect just for my own trusted IP address
RewriteCond %{REMOTE_ADDR} ^206\.83\.102\.77
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?it=$1 [L,QSA]

When you're finished you'd revert the .htaccess to how it was before.

This seems good enough to me, unless you can see a downside.