Комментируем все строки интерфейса по умолчанию ens3
А приведёт ли комментирование к тому, что хостинг перестанет принимать пакеты на этот IP-адрес и перенаправлять их в VDS? Если нет, то утверждение «это исключает какое-либо внешнее воздействие» становится неверным
Ну например в бэкендах веб-сайтов тяжёлых вычислений особо нету, а тормоза обычно возникают из-за этой самой врождённой тормознутости питона. Если JIT может помочь их ускорить, это было бы классно
RSS-Bridge заявляет поддержку Дзена (и ещё с полтысячи других сервисов). Если лень поднимать свой инстанс, можно использовать какой-нибудь чужой публичный (но ссылок специально не дам, чтобы случайно не захабраэффектить)
То есть вы намекаете, что feelamee несёт чушь и его фраза «В плюсах сделаете { }» не имеет смысла? Ну, вы там сами друг с другом разберитесь тогда, я просто мимо проходил)
Принципиальное отличие раста от сишечек в том, что для написания небезопасного кода нужно СПЕЦИАЛЬНО, находясь в здравом уме и твёрдой памяти, приложить усилия и осознанно написать в коде слово «unsafe» — а «токсичное» Rust-сообщество ещё и заставит написать рядом «SAFETY:» комментарий с доказательством, почему этот unsafe не нарушит безопасность.
В сишечках можно написать небезопасный код СЛУЧАЙНО — по недосмотру, по невнимательности, по забывчивости, по неаккуратному рефакторингу. Так и появляется большинство багов и уязвимостей от простых сегфолтов до heartbleed.
Так всё-таки что будет, если СЛУЧАЙНО не выспаться и забыть "сделать { }"?
Ну, от языка это уже не зависит, в сишечках будет то же самое, только сишечный компилятор уже не проконтролирует корректность кода.
Если очень хочется, можно проверить длину динамического массива один раз перед работой с ним, тогда, как описано в том посте, компилятор скорее всего сможет понять, что проверка уже выполнена, и свои проверки добавлять не будет.
Если очень-очень хочется, можно использовать unsafe-методы для обращения к массиву без проверки — только вот скорее всего не нужно
это защита стоит процессорного времени, причем при каждом обращении к массиву.
Если компилятор сможет убедиться, что код в принципе не может выйти за пределы массива, то рантаймовые проверки будут выкинуты за ненадобностью. Вот целый пост был об этом https://habr.com/ru/companies/otus/articles/718012/
Как я уже написал, HttpOnly-куку прочитать не получится, поэтому украсть refresh-токен через XSS не получится (только временно попользоваться в рамках доступности XSS). И CSRF для refresh-токена, кажется, тоже неприменим: даже если злоумышленник сможет каким-то образом отправить refresh-запрос со стороннего сайта, прочитать ответ с присланным access-токеном он не сможет уже никак — браузер не даст доступ, если вы сами не налажаете в настройках CORS
А может, тоже из базы, если будут причины, по которым база окажется удобнее. Поскольку это ограничение не техническое, а скорее всего юридическое — выглядит как хороший кандидат для переноса в services
их лучше выполнять не на уровне со views, а на уровне с services (где бизнес-логика)
В итоге проверка входных данных рубится на две части (в особо запущенных случаях может и на три), и пользователь не сможет получить одновременно «Visa мы не поддерживаем» и «email уже используется» — ему придётся отправить форму два раза, чтобы получить обе ошибки по очереди. Похоже, с этим тоже никто не заморачивается, да и вообще звучит как мелочь, но вот лично мне такое неприятно и хочется поныть
потом чистим значения в базе
Я хочу оставить старые значения в покое и ограничить только новые. Так что, видимо, это тоже уезжает в services
бек отвечает, например, кодом ошибки
Наверное тоже вариант (и в каком-нибудь Cerberus примерно так и сделано), но заводить целый реестр кодов ошибок на каждый чих — чёт даже не знаю
(Я бы ещё поныл про рендеринг html-форм на стороне бэкенда с выводом всех этих ошибок валидации, но в 2024 году меня за такое определённо заклюют)
По сути это не столько валидация, сколько парсинг — просто проверка того, что клиент прислал не совсем откровенный мусор. В реальности к этому добавляются примерно такие штуки, не рассмотренные в посте:
«email уже используется» или «выбранный объект не существует» — это вскользь упомянуто в посте, но не рассмотрено, а ведь сходить в базу (скорее всего асинхронно, 2024 год всё-таки) и проверить там наличие или отсутствие введённого значения всё равно так или иначе придётся;
валидация только при изменении — если значение не изменилось (опять же ходим в базу за старым значением), то свежедобавленные правила валидации не применяем, чтобы не злить старых пользователей;
более хитрый вариант — выполнить валидацию длины нового текста только если он длиннее старого (да, это реальная проверка, которую мне пришлось сделать на одном из моих сайтов);
локализация — не забываем, что тексты ошибок должны быть на родном пользователю языке и быть понятными ему (то есть, например, для встроенных валидаторов нужно заменить сухое «значение не соответствует регулярному выражению [A-Za-z0-9 ]+» на дружелюбное «допустимы только английские буквы, цифры и пробел»).
Из знакомого мне обработать всё это более-менее внятно может разве что Django Forms, но это древнее зло, про которое никто уже не вспоминает, а в современных проектах как будто никто даже не пытается разруливать такие вещи — все тупо выполняют валидацию на фронте, а ошибки с бэка иногда вообще не выводят, и приходится смотреть мониторинг сети в девтулзах, чтобы понять, что я ввёл не так :(
При беглом просмотре заметил только два отвала — N+1 (потому что у сайта случился редизайн) и телеграм (потому что он вредный и даёт ссылки, протухающие примерно через сутки), остальное всё на месте
первоисточники имеют свойство протухать
А должна ли эта проблема иметь отношение к RSS? RSS-читалки — это в первую очередь ленты новостей, а не архивы интернета. Что-то нужное можно вручную сохранить локально или в Wayback Machine, а 99.9% моей ленты — это новости типа «прочитал и забыл», хранить которые мне не нужно (вот на скриншоте выше я ни одну из этих записей даже не читал, лол)
Сразу видно новичка, который не в курсе про аннотации типов
В тех областях, где питон обычно используется, это не имеет почти никакого значения
А вы не допускаете вариант, что расширение было (или стало) вредоносным?
От такого по идее должен спасать userns-remap
У
docker execесть опция--userА приведёт ли комментирование к тому, что хостинг перестанет принимать пакеты на этот IP-адрес и перенаправлять их в VDS? Если нет, то утверждение «это исключает какое-либо внешнее воздействие» становится неверным
Ну например в бэкендах веб-сайтов тяжёлых вычислений особо нету, а тормоза обычно возникают из-за этой самой врождённой тормознутости питона. Если JIT может помочь их ускорить, это было бы классно
Во многих линуксах по умолчанию уже включен zswap, и включать zram скорее всего не нужно (а включать его одновременно с zswap вообще вредно)
Ну как минимум можно посмотреть список роутов в том же rsshub (правда, не все из них именно что перестали, но некоторые наверно всё-таки переставшие)
А из переставших, на что нарвался лично я — ИА «Панорама» )
RSS-Bridge заявляет поддержку Дзена (и ещё с полтысячи других сервисов). Если лень поднимать свой инстанс, можно использовать какой-нибудь чужой публичный (но ссылок специально не дам, чтобы случайно не захабраэффектить)
«какой-то недотепа» в принципе не станет использовать unsafe в своём Rust-коде, потому что нафиг оно ему надо?
Вы тут сами unsafe зачем-то приплели, хотя вас всего лишь про «сделать { }» спросили
То есть вы намекаете, что feelamee несёт чушь и его фраза «В плюсах сделаете { }» не имеет смысла? Ну, вы там сами друг с другом разберитесь тогда, я просто мимо проходил)
Нельзя.
Принципиальное отличие раста от сишечек в том, что для написания небезопасного кода нужно СПЕЦИАЛЬНО, находясь в здравом уме и твёрдой памяти, приложить усилия и осознанно написать в коде слово «unsafe» — а «токсичное» Rust-сообщество ещё и заставит написать рядом «SAFETY:» комментарий с доказательством, почему этот unsafe не нарушит безопасность.
В сишечках можно написать небезопасный код СЛУЧАЙНО — по недосмотру, по невнимательности, по забывчивости, по неаккуратному рефакторингу. Так и появляется большинство багов и уязвимостей от простых сегфолтов до heartbleed.
Так всё-таки что будет, если СЛУЧАЙНО не выспаться и забыть "сделать { }"?
Не скомпилится, компилятор заявит, что значение не живёт достаточно долго
Ну, от языка это уже не зависит, в сишечках будет то же самое, только сишечный компилятор уже не проконтролирует корректность кода.
Если очень хочется, можно проверить длину динамического массива один раз перед работой с ним, тогда, как описано в том посте, компилятор скорее всего сможет понять, что проверка уже выполнена, и свои проверки добавлять не будет.
Если очень-очень хочется, можно использовать unsafe-методы для обращения к массиву без проверки — только вот скорее всего не нужно
Дыру в Rust-компиляторе найдут и исправят, фикс автоматически применится для всех Rust-программ, собранных новым компилятором.
Миллионы выходов за пределы массива, use-after-free и прочих UB в миллионах сишных программ не найдут и не исправят никогда.
Если компилятор сможет убедиться, что код в принципе не может выйти за пределы массива, то рантаймовые проверки будут выкинуты за ненадобностью. Вот целый пост был об этом https://habr.com/ru/companies/otus/articles/718012/
Как я уже написал, HttpOnly-куку прочитать не получится, поэтому украсть refresh-токен через XSS не получится (только временно попользоваться в рамках доступности XSS). И CSRF для refresh-токена, кажется, тоже неприменим: даже если злоумышленник сможет каким-то образом отправить refresh-запрос со стороннего сайта, прочитать ответ с присланным access-токеном он не сможет уже никак — браузер не даст доступ, если вы сами не налажаете в настройках CORS
А может, тоже из базы, если будут причины, по которым база окажется удобнее. Поскольку это ограничение не техническое, а скорее всего юридическое — выглядит как хороший кандидат для переноса в services
В итоге проверка входных данных рубится на две части (в особо запущенных случаях может и на три), и пользователь не сможет получить одновременно «Visa мы не поддерживаем» и «email уже используется» — ему придётся отправить форму два раза, чтобы получить обе ошибки по очереди. Похоже, с этим тоже никто не заморачивается, да и вообще звучит как мелочь, но вот лично мне такое неприятно и хочется поныть
Я хочу оставить старые значения в покое и ограничить только новые. Так что, видимо, это тоже уезжает в services
Наверное тоже вариант (и в каком-нибудь Cerberus примерно так и сделано), но заводить целый реестр кодов ошибок на каждый чих — чёт даже не знаю
(Я бы ещё поныл про рендеринг html-форм на стороне бэкенда с выводом всех этих ошибок валидации, но в 2024 году меня за такое определённо заклюют)
По сути это не столько валидация, сколько парсинг — просто проверка того, что клиент прислал не совсем откровенный мусор. В реальности к этому добавляются примерно такие штуки, не рассмотренные в посте:
«email уже используется» или «выбранный объект не существует» — это вскользь упомянуто в посте, но не рассмотрено, а ведь сходить в базу (скорее всего асинхронно, 2024 год всё-таки) и проверить там наличие или отсутствие введённого значения всё равно так или иначе придётся;
валидация только при изменении — если значение не изменилось (опять же ходим в базу за старым значением), то свежедобавленные правила валидации не применяем, чтобы не злить старых пользователей;
более хитрый вариант — выполнить валидацию длины нового текста только если он длиннее старого (да, это реальная проверка, которую мне пришлось сделать на одном из моих сайтов);
локализация — не забываем, что тексты ошибок должны быть на родном пользователю языке и быть понятными ему (то есть, например, для встроенных валидаторов нужно заменить сухое «значение не соответствует регулярному выражению [A-Za-z0-9 ]+» на дружелюбное «допустимы только английские буквы, цифры и пробел»).
Из знакомого мне обработать всё это более-менее внятно может разве что Django Forms, но это древнее зло, про которое никто уже не вспоминает, а в современных проектах как будто никто даже не пытается разруливать такие вещи — все тупо выполняют валидацию на фронте, а ошибки с бэка иногда вообще не выводят, и приходится смотреть мониторинг сети в девтулзах, чтобы понять, что я ввёл не так :(
Картинки живы-здоровы
При беглом просмотре заметил только два отвала — N+1 (потому что у сайта случился редизайн) и телеграм (потому что он вредный и даёт ссылки, протухающие примерно через сутки), остальное всё на месте
А должна ли эта проблема иметь отношение к RSS? RSS-читалки — это в первую очередь ленты новостей, а не архивы интернета. Что-то нужное можно вручную сохранить локально или в Wayback Machine, а 99.9% моей ленты — это новости типа «прочитал и забыл», хранить которые мне не нужно (вот на скриншоте выше я ни одну из этих записей даже не читал, лол)