Bug #98330
closed
PHP warning log with EXT-syntax using asset vh in BE
0%
Description
Description
When using an asset view helper in the backend context referencing a resource from a 3rd party extension a php warning entry is added to the sys_log table. The behavior can be observed when the php configuration `open_basedir` is set and "Live" is selected as debug settings in the configuration presets from the settings module. The warning log entry looks as following:
Core: Error handler (BE): PHP Warning: file_exists(): open_basedir restriction in effect. File(/typo3conf/ext/pizpalue/Sysext/backend/Resources/Public/Css/LayoutModule/collapsible-content-element.css) is not within the allowed path(s): (/home/httpd/vhosts/domain.ch/:/tmp/) in /home/httpd/vhosts/domain.ch/httpdocs/pizpalue/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php line 2317
Example use case
An extension with the extension key myext overwrites the partial `PageLayout/Record.html` from the system extension "backend" and uses an asset view helper in the overriding partial as following:
<f:asset.css identifier="myext-backend" href="EXT:myext/Path/To/Css/custom.css" />
Findings
- The log entry can be avoided by adjusting the global configuration `[SYS][belogErrorReporting]`
- When checking for file existence in `GeneralUtility` the `open_basedir` could be checked using `ini_get('open_basedir')` prior using `file_exists()`
Updated by Jonas Eberle about 2 years ago
Is that extension installed?
I can't reproduce with
<f:asset.css identifier="ext-styleguide" href="EXT:styleguide/Resources/Public/Css/frontend.css" />
in a backend template with installed EXT:styleguide.
Updated by Roman Büchler about 2 years ago
Jonas Eberle wrote in #note-1:
Is that extension installed?
I can't reproduce with
[...]
in a backend template with installed EXT:styleguide.
Could you set a breakpoint at [GeneralUtility.php#L2158](https://github.com/TYPO3-CMS/core/blob/8f4d7dd84ca36f626676250b493d26c2bcce7851/Classes/Utility/GeneralUtility.php#L2158) and check the path for that asset? On my side it starts with `/typo3conf` which should trigger a php warning related to open_basedir.
Updated by Benni Mack about 2 years ago
- Related to Bug #98545: file_exists(): open_basedir restriction in effect added
Updated by Benni Mack about 2 years ago
- Related to Bug #98152: PHP Warning: file_exists(): open_basedir restriction in effect. added
Updated by Benni Mack over 1 year ago
- Target version changed from 12 LTS to Candidate for patchlevel
Updated by Benni Mack over 1 year ago
- Status changed from New to Needs Feedback
Hey Roman,
can you please give some feedback?
Updated by Roman Büchler over 1 year ago
Jonas Eberle wrote in #note-1:
Is that extension installed?
I can't reproduce with
[...]
in a backend template with installed EXT:styleguide.
... yes, the extension is installed.
Updated by Roman Büchler over 1 year ago
Roman Büchler wrote in #note-2:
Jonas Eberle wrote in #note-1:
Is that extension installed?
I can't reproduce with
[...]
in a backend template with installed EXT:styleguide.
Could you set a breakpoint at [GeneralUtility.php#L2158](https://github.com/TYPO3-CMS/core/blob/8f4d7dd84ca36f626676250b493d26c2bcce7851/Classes/Utility/GeneralUtility.php#L2158) and check the path for that asset? On my side it starts with `/typo3conf` which should trigger a php warning related to open_basedir.
I tried to debug it but didn't manage yet to inspect the suggested breakpoint. In my ddev environment I added
open_basedir = /var/www/html
to ".ddev/php/custom.ini" and then get a similar error accessing the be login:
PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/www/html/.build/vendor/bk2k/bootstrap-package/Resources/Public/Icons/ContentElements/container-columns-1.svg) is not within the allowed path(s): (/var/www/html) in /var/www/html/.build/vendor/b13/container/Classes/Tca/Registry.php line 115
Updated by Georg Ringer 6 months ago
- Related to Bug #101350: open_basedir restriction in effect added
Updated by Georg Ringer 5 months ago
- Status changed from Needs Feedback to Resolved
I couldn't reproduce that in v13, therefore closing the issue.
if you still are affected by this, please open a new issue and reference this one or contact me on slack