Tdvist, это вряд ли. И еще непонятно, почему вы указываете заголовок: 'Content-Type': 'multipart/form-data'
Так делать не нужно, браузер сам пропишет этот заголовок, если передается корректный FormData. Дело в том, что именно в таком виде заголовка недостаточно, надо еще в нем же указать использованный разделитель - браузер это делает сам.
Если бы я все это на своем сервере делал, то никаких проблем, но мне надо коробочное решение подготовить для пользователя, чтобы он залил код в корень сайта и больше не парился. Парится над ошибками буду я)
Дмитрий, ну так против headless ничего не поможет, в принципе. От такого невозможно защитится, если у злоумышлиника есть деньги на прокси и есть ресурсы для запуска ручных браузеров.
Здесь разве какую-то систему аунтефикации прикручивать, например, по номеру телефона или через профили в соц. сетях. И то даже это не защита, было бы желание и это обходится.
Ипатьев, я не спорю, что обойти очень легко, но чтобы это сделать надо в принципе знать, что она есть. Никто не будет распутывать обфусцированный js код когда сервер отвечает успехом всегда, а структура запроса очевидна. Обычное вот такие тупые и дебильные защиты хорошо работают. По поводу времени... так и не надо брать время с компа клиента, брать время сервера как опору при вычислениях порядка аргументов.
Stalker_RED, ого, не знал что есть такая полезная функция. Огромное спасибо за наводку.
Ипатьев, а как применить метод toString? Просто вызвать? $e->toString()
Или попытаться привести обьект к строке? (string)$e
Я ведь не вывести его хочу, мне именно полный текст ошибки нужен, чтобы я его мог положить в переменную и уже дальше его отослать себе удобным мне способом.
Ипатьев, не понимаю... чтобы что-то отправить в телеграм это что-то должно быть строкой, а $e объект, поэтому я вынужден из его свойства сначала сформировать текст.
По поводу того, что бы обрабатывать ошибки в одном месте... да я вроде это и собираюсь делать, единый try catch в основном php файле (роутере), чтобы централизовать их мониторить. Или вы что-то иное имели в виду?
Я их ловлю не для того, чтобы вывести, а чтобы отправить себе в телеграм. При том, если посмотреть содержимое $e->getMessage() то там нет указания в каком именно файле ошибка и в какой именно строке.
За совет спасибо, действительно с типом Throwable перехватывается все: catch (Throwable $e) { }
Богдан Кучерук, так с этого и надо было начинать, что вы пилите WYSIWYG редактор. Дело в том, что это не то чтобы безнадежная затея, просто это очень сложно будет сделать кроссбраузерно. Плюс, учитываем, что это гарантированно будет влеосипед, так как все что можно и нельзя на этом поприще уже изобретено.
Правильным здесь будет взять уже готовый WYSIWYG редактор, например тот же TinyMCE и уже его кастомизировать под свои хотелки. Вот пример плагина который подсвечивает ссылки: https://www.tiny.cloud/docs/plugins/opensource/aut...
По идее с небольшой доработкой он сможет подсвечивать и хештеги.
Богдан Кучерук, вы кстати идею с 2мя полями не уловили, это может быть и не textarea, а два contenteditable, в одном выполняется ввод, а во втором отображение после обработки. При такой схеме работы не нужно будет с позицией курсора мучатся, так как мы не трогаем ввода пользователя и не отменяем события.
Богдан Кучерук, один из вариантов реализации такой системы, это ввод делать в одном поле, а выводить (отображать) в другом. При том если уж так сильно надо, то ничто не мешает наложить поле, где отображение идет, поверх поля, где идет ввод. Например: https://nadim.work/hashtag.html
Богдан Кучерук, мда, тут у вас изначально неверный поход, в этом деле не нужно использовать регулярные выражения в принципе, да и форма у вас никак не защищена от вставки html мусора. Я постараюсь завтра скинуть вам пример с комментариями.
'Content-Type': 'multipart/form-data'Так делать не нужно, браузер сам пропишет этот заголовок, если передается корректный FormData. Дело в том, что именно в таком виде заголовка недостаточно, надо еще в нем же указать использованный разделитель - браузер это делает сам.