base64 mimetype and file extensions

[SlyDave]

Hello,

We're uploading some files via base64, the mime-type of the file isn't known at the point of upload but is of course encoded in the base64. Unfortunately, medialibrary doesn't set the file extension correctly when adding media via addMediaFromBase64(). it always set the extension to .tmp -- this is despite the fact, inside the addMediaFromBase64() method there is a mime-type check (using the temp stored file).

The problem I have is I cannot get the mime-type of the file as the FileAddr created by addMediaFromBase64() doesn't expose it, so I either have to implement most of what addMediaFromBase64() does so I can get the mime-type to get the file extension to call usingFileName() or I have to add the file with tmp, then update and move the media already stored.

I've noticed multiple recorded issues and discussion around this point and the answer provided is always use usingFileName() but that doesn't work if you don't know the mime-type, and you need to infer it from the base64.

It seems to me that given addMediaFromBase64 already knows and checks the mime-type, it could just name the file correctly in the first place.

e.g.: This works great if the base64 encode is actually a .png, but if it's a .jpg, the file ends up with the wrong extension.

$avatar = $this->addMediaFromBase64($base64Avatar)
                    ->usingFileName("user-avatar-{$this->id}.png")
                    ->toMediaCollection('avatar');

Whereas the following results in the file being called .tmp

$avatar = $this->addMediaFromBase64($base64Avatar)
                   ->toMediaCollection('avatar');

And the below updates the file with the correct extension, but requires another database query, and another hit against the storage device, it is also recommended to set 'moves_media_on_update' => true, in the media-library config file.

The problem with this is if all you do is change the extension and not the path, the syncMedaPath() call in the updating() method of the MediaObserver then fails with File already exists at path: <path> -- it shouldn't complain to fail to move the file if the file hasn't moved as it is a sync operation.

        $avatar = $this->addMediaFromBase64($base64Avatar)
                    ->toMediaCollection('avatar');

        $ext = MimeTypes::getDefault()->getExtensions($avatar->mime_type)[0] ?? null;
        $filename = pathinfo($avatar->file_name, PATHINFO_FILENAME);

        if ($ext) {
            $avatar ->file_name = "{$filename}.{$ext}";
            $avatar ->save();
        }

None of these are practical solutions, it would be so much simpler if addMediaFromBase64() just set the file extension correctly, it already has all the information available...

Unless I'm missing something?

[systemsolutionweb]

Feel free to make a PR

[SlyDave]

My work around above no longer works as of 01/03/2023

I don't know if it's because I upgraded to v10 of medialibrary or if AWS changed something with S3.

But since then, calling save() on $avatar to rename the file_name causes conversions to run resulting in the following error:

Error executing "CopyObject" on "https://<host>.s3.amazonaws.com/avatars/5fa781e5-ca90-43f0-9142-9f1a27291e89/conversions/3f9c8ae5-7104-43b5-8b57-b4b47a4e6f23-thumb.jpg";
AWS HTTP error: Client error: `PUT https://<host>.s3.eu-west-2.amazonaws.com/avatars/5fa781e5-ca90-43f0-9142-9f1a27291e89/conversions/3f9c8ae5-7104-43b5-8b57-b4b47a4e6f23-thumb.jpg` resulted in a `400 Bad Request` response:

<Error><Code>InvalidRequest</Code><Message>This copy request is illegal because it is trying to copy an object to itself (truncated...)
 InvalidRequest (client): This copy request is illegal because it is trying to copy an object to itself without changing the object's metadata, storage class, website redirect location or encryption attributes. - <Error><Code>InvalidRequest</Code><Message>This copy request is illegal because it is trying to copy an object to itself without changing the object's metadata, storage class, website redirect location or encryption attributes.</Message><RequestId>...</RequestId><HostId>...</HostId></Error>

[SlyDave]

Thanks for the incredibly useful reply, maybe you should create a PR and fix it to show everyone how it's done?

[angeljqv]

your comment is just as useful, complaining for years and doing absolutely nothing about it
this is open source, you are not paying anyone to do the work for you, apparently you don't know about it, read license

laravel-medialibrary/LICENSE.md

Lines 15 to 21 in 2d18551

	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
	FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
	AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
	LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
	OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
	THE SOFTWARE.

I thought you noticed that we all ignore you, but you keep complaining

[SlyDave]

Actually, it's not only open source, there is a paid version, of which I pay, but that's neither here nor there.

As for the work arounds and such, maybe just maybe, people need to use things before the entire peer review process, PR merge process and release process all take place and waiting for the process blocks them from continuing the work/project/solution. Perhaps people aren't confident in contributing to the produce or they don't know the solution or don't feel that their solution is complete or correct? Maybe just make that's why they posted it under discussion and not issue?

Also, quick aside, "doing absolutely nothing about it", that's why there is a detailed description in this discussion post on how to work around it, and indeed once a possible fix was identified a issue was raised with a further detailed explanation on how the problem occurs and what a fix might look like. -- not sure what constitutes "nothing" to you, but that isn't it. So much for people banding together and helping each other, no. your approach is to be vastly more insular "do it yourself noob" seems to be your writing between the lines.

Simply brushing people aside with a "make a PR" isn't helpful to the community. I'd go as far to say it's quite the opposite and unfortunately come across as rather toxic. As sadly do your final words.

I'd also like to add that you posting the LICENSE and claiming I'm complaining is a bit of a misread, at no point do I demand fixes or whine about bugs or issue. No rather, I opened a discussion on something I found, looked into and the issues I encountered, I then at at a later date updated it with additional information on the issue. It's fine if you don't want to engage in any discourse, you can simply continue to ignore the thread without posting unhelpful information and petty remarks. But thanks all the same, you appear to have brought light to the subject, so at least you've been of some use in the end. 😂

I'm going to assume you don't represent Spatie or @freekmurze and given how much great work he has done and continues to do for this community, I'm fairly sure he'd not be all too impressed with some members attitudes towards other members.

[PaolaRuby]

Lol, too much to read, you could use your time better

[SlyDave]

ah, trolls. got it. have a good day 👍

[layerok]

My workaround. I simply overwrote InteractsWithMedia trait.

use Spatie\MediaLibrary\InteractsWithMedia as BaseInteractsWithMedia;

trait InteractsWithMedia
{
    use BaseInteractsWithMedia;

    public function addMediaFromBase64(string $base64data, array|string ...$allowedMimeTypes): FileAdder
    {
        // ...
        $fileInfo = finfo_open();
        $mime_type = finfo_buffer($fileInfo, $binaryData, FILEINFO_EXTENSION);
        $tmpFile = tempnam(sys_get_temp_dir(), 'media-library').".$mime_type";
        // ...
    }
}