Right, so I think the only issue would be when we hide the path to {main} and
anything relative to that. The trade-off would be that the developer will need
to be familiar with his/her own directory structure. After thinking about it
some more, there is the possibility that there are multiple scripts with the
same name at multiple levels (e.g. /www/a.php and /www/deeper/a.php) that both
might be accessed directly. Therefore, I think we should use the document root
(I can't imagine a case where PHP would not know it), in case it is different
from PHP_SELF (not familiar with how they work together). I don't know of
another way that would be useful for max_input_vars errors and similar.
Comparatively, if we hide anything in the include path, and replace it with
[inc], the developer will know it's in one of the include paths.
Any other custom paths and replacements would usually be developer specified
like fpd_hide_path('/home/acct/git/lib', '[git]'), so the developer would be
able to figure it out.
If the error is written to a log file, I'm not sure that there is a reason to
filter paths in the log file, but maybe you want to provide an option for it.
My suggestion is mainly for errors that are sent to the browser or that are
likely to be sent to the browser after being caught (debug_backtrace).
Here's a case showing what happens to the document root:
Before:
-------
Fatal Error: Uncaught Error: Call to undefined method
Fake_Class::nonexistent_method() in /home/acct/www/script.php:2
Stack trace: #0 {main} thrown in /home/acct/www/deep/script.php on line 2
After:
------
Fatal Error: Uncaught Error: Call to undefined method
Fake_Class::nonexistent_method() in /[path]/script.php:2
Stack trace: #0 {main} thrown in /[path]/deep/script.php on line 2
If the first error is sent to the browser, a third party learns the site's acct
name on the web server.
If the second error is sent to the browser, the third party doesn't really
learn anything.
When the traces get longer, and we include files above the root for some
reason, maybe I would say just use /[path]/../sidepath if there's not a
specific replacement for it. This would only be an problem if users are
including files from other people's accounts or are using really strange paths;
even so, the output wouldn't disclose any more information than the current
implementation.
Thanks,
Ted
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
