Restricted Assets Download via request-data mechanism not working

[galum]

Q	A
Bug report?	yes

Asset Download via members/request-data/(token) mechanism seems not working any more (Pimcore 5.7.1, Members Bundle v2.3.0, PHP 7.2, Apache). Only the first few bytes of the requested files are download. The file is thus downloaded broken. The problem is most probably in how the response is created in RequestController / serveFile function:

        $response->setCallback(function () use ($asset) {
            flush();
            ob_flush();
            $handle = fopen(rawurldecode(PIMCORE_ASSET_DIRECTORY . $asset->getFullPath()), 'rb');
            while (!feof($handle)) {
                print(fread($handle, self::BUFFER_SIZE));
                flush();
                ob_flush();
            }
        });

Maybe the use of flush() is causing problems or maybe an other problem. In a quick test, I replaced the Response for download with Symfony's BinaryFileResponse and then it worked:

            $response = new BinaryFileResponse($asset->getFileSystemPath(), 200, [], false, null, true, true);
            $response->headers->set('Content-Type', $asset->getMimetype());
            $response->headers->set('Content-Length', $asset->getFileSize());
            $response->headers->set('Cache-Control', 'private');

The function serveZip also uses a similar mechanism and may also be effected.

EDIT: I just saw that in the current version in the repository the print function in this part has been replaced with the echo function. So maybe this problem has already been solved in the latest version.

EDIT2: In a similar situation, we used StreamedResponse in the way it is documented here:
https://medium.com/@matriphe/streaming-csv-using-php-46c717e33d87
Maybe writing to $handle=fopen('php://output', 'w'); would be better than using "print" or "echo". Flush ist not used there at all in the example.

[solverat]

Hey @galum,

i just tested the zip generation by using a simple twig call and it worked perfectly fine:

 {{ dump(members_generate_asset_package_url([11,12], true)) }} 

11 and 12 are asset ids (which must be available in the /restricted-assets assets folder.

Did you also tried the latest dev-master? If not, please do so. We also need some more information, if the problem still exists: total file size, file type, file amount.

Thanks!

[galum]

@solverat

By trial and error, I figured out that the problem seems to be this:

$response->headers->set('Content-Length', $asset->getFileSize('noformatting'));

A generated string there is for example 78 KB but the browser will then only download the first 78 bytes!

I replaced it with this:

$response->headers->set('Content-Length', $asset->getFileSize(false));

Output here: 78001

And then it is working.

I assume Pimcore changed something in the getFileSize behaviour. The first argument is a boolean(!):

/**
* Get filesize
*
* @param bool $formatted
* @param int $precision
*
* @return string
*/
public function getFileSize($formatted = false, $precision = 2)

Edit 1:
The problem was not with the ZIP download but with the single file download (serveFile)!

[solverat]

@galum you're right... they really changed that. jeez...
I'm going to change this - big thanks for your investigation!

(for reference: pimcore/pimcore#3885)
(for reference II: implement tests #73)

[solverat]

fixed

[galum]

@solverat

Thanks for your efforts!

[Sonja-Schubert]

@solverat and @galum Thank you very much for solving this!
@solverat Is there already a time schedule when 2.4.0 will be released? We use these restricted asset downloads a lot also in production env so it would be great to have a release to not use the master branch

[solverat]

Hey @Sonja-Schubert, just released version 2.4.0! Enjoy!