Bug #51831
closed
FE: $GLOBALS['BE_USER']->getFileStorages() fileMounts array is empty (after switch from 6.1.3 to 6.1.4)
Added by Gerrit Mohrmann about 11 years ago.
Updated about 11 years ago.
Category:
File Abstraction Layer (FAL)
Description
In backend filelist it is ok!
In frontend I have no fileMounts after the switch.
The debug output from $GLOBALS['BE_USER']->getFileStorages() is diffrent from 6.1.3 to 6.1.4.
[fileMounts:protected] => Array
(
... empty in 6.1.4 FE...
)
[userPermissions:protected] => Array
(
... empty in 6.1.4 FE...
)
only in 6.1.4:
[evaluatePermissions:protected] =>
Backend $GLOBALS['BE_USER']: TYPO3\CMS\Core\Authentication\BackendUserAuthentication Object
Frontend $GLOBALS['BE_USER']: TYPO3\CMS\Backend\FrontendBackendUserAuthentication Object
In BackendUserAuthentication are some changes, can it have side effects?
Files
Here are more infos from the reporter posted on list (typo3.dev) - (please in future post all relevant infos here in the issue too):
For Webdav I initialize an BackendUser with
$GLOBALS['BE_USER'] = t3lib_div::makeInstance('t3lib_tsfeBeUserAuth')
<...>
//Get the fileMounts:
$GLOBALS['BE_USER']->fetchGroupData();
$storages = $GLOBALS['BE_USER']->getFileStorages();
foreach ($storages as $storageObject) {
$storageMounts = $storageObject->getFileMounts();
if (count($storageMounts)) {
foreach ($storageMounts as $storageMountInfo) {
$fileMounts[] = array(
'path' => $storageMountInfo['folder']->getPublicUrl(),
'name' => $storageMountInfo['title'],
);
}
}
}
It's fine bevor the security fix, after it is broken. When debuging I can see the Storage but not the Filemounts.
Permissions are set in UserGroupTS and for testing in UserTS too:
permissions.file.default {
addFile = 1
..
}
permissions.file.storage.1 {
addFile = 1
..
}
Or have I todo more to see the Filemounts again?
Ernesto Baschny wrote:
Or have I todo more to see the Filemounts again?
What is the usecase here? How should the storages be used?
The fileMounts from BackendUser are needed to mount them in webdav server SabreDav
Used ext:webdav with some changes for newer SabreDav version, FAL Storage Filemounts from BeUser, Digest Auth ... and maybe more.
I think the intresting part is in the file:
webdav/Classes/Controller/WebdavController.php (attached, with changes)
- Status changed from New to Needs Feedback
Gerrit Mohrmann wrote:
Used ext:webdav with some changes for newer SabreDav version, FAL Storage Filemounts from BeUser, Digest Auth ... and maybe more.
I think the intresting part is in the file:
webdav/Classes/Controller/WebdavController.php (attached, with changes)
Thanks, can you please let us know what the original source of this extension was?
Did you load it from the TER or from SVN/Github/Git/...? And what is the version of EXT:WebDAV you're using?
Gerrit Mohrmann wrote:
Used ext:webdav with some changes for newer SabreDav version, FAL Storage Filemounts from BeUser, Digest Auth ... and maybe more.
The webdav extension manually instantiates a BE_USER in frontend context, simulating a backend authentication.
I'm not sure if we need to support that.
We should think however about the expected behavior in frontend, especially when a backend user is logged in.
You can also work around your problem by adding the signal yourself after the BE_USER is initialized and before storages are fetched:
\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Extbase\\SignalSlot\\Dispatcher')->connect(
'TYPO3\\CMS\\Core\\Resource\\ResourceFactory',
\TYPO3\CMS\Core\Resource\ResourceFactory::SIGNAL_PostProcessStorage,
'TYPO3\\CMS\\Core\\Resource\\Security\\StoragePermissionsAspect',
'addUserPermissionsToStorage'
);
Helmut Hummel wrote:
You can also work around your problem by adding the signal yourself after the BE_USER is initialized and before storages are fetched:
[...]
Thanks for the hint Helmut. It works!
I'm not sure if we need to support that.
If so, the issue can be closed. Solved for me.
- Status changed from Needs Feedback to Closed
Thanks you for reporting back on this. Closed.
Also available in: Atom
PDF