Не знаю, может кто встречался с этим. Наверное, проблема не только Laravel касается, но у меня она появилась именно в Laravel. Использую валидатор mimes для ограничения типов файлов, принимаемых сайтом. И обнаружил интересную такую вещь. Если сайту скормить файл ворда, но не созданный на своём компе, а скаченный, к примеру, из контакта, то валидатор считает, что он не word-файл, а octet stream. Я посмотрел, браузер тоже в заголовках посылает именно этот тип. Есть ли для Laravel валидатор, который бы проверял mime по самому файлу?
Поигрался. Всё даже ещё интереснее. По ходу, браузер не определяет mime ворда, если они созданы в Libre Office. Проверить на MS Office не могу, его у меня нету. И валидатор видимо тоже не сам проверяет тип, а берёт который браузер подставил. Валидатор настроен на расширения jpeg,bmp,png,pdf,doc,docx,xls,xlsx,zip --- Добавлено --- В лисе тоже: Странно. Надо попробовать прогнать через http://php.net/mime_content_type, но это позже. Что-то я подозреваю, что если браузер не определяет, то эта штука тоже не сможет.
Можно попробовать открыть и тот и тот файлы в текстовом редакторе, посмотреть, где они хранят заголовки служебные и мету. Обычно это первые байты от старта файла. Чтоб поглядеть, именно вот в файле так зашито, или проблема в другом месте. Если в этих данных реально есть разница - то тогда городить костыли. Если и там и там есть общие маркеры - тогда дергать mime самому, читая и парся эти вот первые байты файла ручками.
Залез дальше, дебагером внутрь. Laravel умный, он проверяет как раз сам файл, а не то, что там ему говорит браузер. КОроче, такой mime-тип для этих файлов даёт вот этот класс: Symfony\Component\HttpFoundation\File\MimeType\FileinfoMimeTypeGuesser, который в свою очередь использует https://php.ru/manual/class.finfo.html... Т.е. php тоже не может определить --- Добавлено --- И второй проверяльщик из Symphony, Symfony\Component\HttpFoundation\File\MimeType\FileBinaryMimeTypeGuesser также даёт octet stream для таких фалов, поскольку его даёт команда linux file, через которую он реализован. Интересно --- Добавлено --- А должен быть application/vnd.openxmlformats-officedocument.wordprocessingml.document --- Добавлено --- Попробовал сделать такой файл в WordPad (Думаю, может из-за Libre) - не, аналогично, не определяется нужный mime... Любые docx дают octet stream. Надо погуглить дальше
В общем, я неправильный сначала вывод сделал. Не определяются вообще файлы docx, а не конкретно скачанные из нета. Любопытненько. Есть какие-то mime magic базы, но я пока не понял, как их устанавливать
Любопытно. Добавил в файлик /etc/magic вот это дело: https://fossies.org/linux/misc/file-5.30.tar.gz:a/file-5.30/magic/Magdir/msooxml, после чего файл, созданный в WordPad успешно загрузился на сайт, а файл созданный в Libre Office по прежнему не грузится...
Мда, а Libre Office он не понимает, не смог нагуглить. А разбирать этот формат файла как-то не особо хочется, да и времени нету. Поставить что-ли дополнительную проверку на расширения, что типа если docx, то принимать в любом случае. Всё равно они кидаются у меня в папку, которую не достать без полного доступа к серверу.
Ну если только так. Главное, чтобы нельзя было таким способом пробить дыру или залить на сервер зловреда исполняемого.
Вообще, у меня ещё такая идея, что docx, которые не смог определить валидатор, пытаться проверять с помощью инструментов работы с zip-архивами (чтоб там были необходимые каталоги). В принципе, поэтому и путаются все эти программы, что это zip-архив. И инструкции в том файле явно именно это и делают, но каким-то мудрёным способом. Ман-то по нему есть, но реально что-то сложно. Надеюсь, что это не будет дорогостоящая по времени операция - считать зип-архив и найти пару имён файлов и папок.
Дороговизна операции определяется еще и частотой исполнения. Для каких-то задач 0.5 секунды недорого, а для каких-то и 10мс - это дофига. Об этом тоже нельзя забывать. Вообще, зип-архивы, и вообще почти любые архивы, технически, являются эдакой виртуальной файловой системой. И доступ к ним, обычно, довольно быстрый. Открытие 1-мегабайтного архива и открытие 100-гигабайтного занимают примерно одинаковое время. Потому что читается не весь архив, а только нодлист его корня. Теоретически, должно быть чууть чуть медленнее обычного захода в каталог.