Project

General

Profile

Actions

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.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2013-09-08
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.1
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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

WebdavController.php (8.82 KB) WebdavController.php Gerrit Mohrmann, 2013-09-11 01:02
Actions #1

Updated by Ernesto Baschny about 11 years ago

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?

Actions #2

Updated by Helmut Hummel about 11 years ago

Ernesto Baschny wrote:

Or have I todo more to see the Filemounts again?

What is the usecase here? How should the storages be used?

Actions #3

Updated by Gerrit Mohrmann about 11 years ago

The fileMounts from BackendUser are needed to mount them in webdav server SabreDav

Actions #4

Updated by Gerrit Mohrmann about 11 years ago

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)

Actions #5

Updated by Oliver Hader about 11 years ago

  • 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?

Actions #6

Updated by Helmut Hummel about 11 years ago

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'
    );

Actions #7

Updated by Gerrit Mohrmann about 11 years ago

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.

Actions #8

Updated by Wouter Wolters about 11 years ago

  • Status changed from Needs Feedback to Closed

Thanks you for reporting back on this. Closed.

Actions

Also available in: Atom PDF