В продолжение темы про OWASP — можно почувствовать себя кулхацкером скрипт-кидди и посмотреть, как работают OWASP Top-10 “вживую”: https://application.security/free/owasp-top-10. На сайте представлены интерактивные примеры, где подробно разжевывают каждый шаг по эксплуатации уязвимости.

Перед любой командой можно приписать timeout Xs, и она будет завершена после указанного времени, если сама не успела завершиться. Например

timeout 5s yes "I WILL NOT WASTE CHALK"

Причем если команда завершилась по таймауту, то будет специальный код возврата (124), а если успела выполнится сама — ее обычный код. Можно еще менять сигнал с TERM на другой, например на HUP или KILL.

Выбор сервера осуществляется по round robin. Если выбранный сервер не ответил, то он кладется в бан-лист на минуту, если при следующем запросе не ответил еще раз — примерно на полторы, с увеличением интервала в 2^(failedAttempts/2) раз вплоть до 30 минут. Если сервер ответил, то он исключается из черного списка. Если живых серверов нет, то пробуем самый недавний из черного списка: если и он не отвечает, то все плохо и кидаем исключение.

Напоминает опрос узлов в краулере на старой работе, хотя там реализация была сложнее (хотя бы потому, что проверять надо было как сами сервера, так и прокси), сброс меток был сделан через сброс всего пула, и состояние шарилось между инстансами. Приятно думать, что это было более-менее адекватное решение.

В районе версии 6.5 ребята из Elasticsearch что-то сообразили и сделали документацию по контекстам Painless. В ней можно посмотреть, какие переменные доступны в скриптах Painless в зависимости от того, какая операция выполняется — reindex, update by query, скриптованный поиск и т.д. Очень не хватало этого, когда работали с 2-5 версиями и писали всякие миграции на этом “замечательном” языке.

Когда пытался понять отличия Thunderbolt 3 от USB 3.X Gen Y Type C, то узнал, что за доставку питания отвечает стандарт USB Power Delivery. И этот стандарт настолько хорош, что можно заряжать телефон от ноутбучной зарядки, если оба этот стандарт поддерживают. Телефон с разъемом USB-C, очевидно, это делает, а на адаптере зарядника от ноута должен быть вариант с 5V/2A. В нормальной технике будет еще защита от неправильных режимов, так что беспокоиться не о чем. Я проверил с рабочим ноутом и телефоном — действительно, работает.

А само отличие Thunderbolt 3 от USB-C в основном заключается в скорости передачи данных и лицензировании (и, как следствие, стоимости). Еще не всякий разъем/кабель USB поддерживает туннелирование сигнала с монитора. Решить это должен USB4, который полностью совместим с Thunderbolt 3 и имеет только один тип разъема, USB-С.

Вообще классно, что через один провод можно передавать любые данные, в т.ч. графику и сеть, а еще и питание. Можно всю периферию и питание цеплять к док-станции, а “тушку” менять — переключаться между рабочим и домашним компом, например. Или вообще телефон воткнуть и работать за ним, как за компом.

Нашел сайтик, на котором можно без регистрации, смс и прочей фигни удалить фон с изображения, особенно если есть повышенная криворукость, как у меня. Не очень сложный фон удаляется автоматически, а мелкие детали можно подредактировать самостоятельно.

Мне пригодилось для создания эмоджи-реакций в слаке (потому что имеющийся набор очень скуден, особенно после миллиардов стикеров в телеге).

Портировать существующий проект с обработкой заявок на Scala JS оказалось довольно легко (ну, с учетом того, что там нет зависимостей): берем туториал, выполняем немного пунктов из него, меняем немного IO — заменяем чтение из файла на чтение из textarea, аналогично меняем main, добавляем простенькую html-ку и готово. Единственное, обо что споткнулся на первой итерации — нужно было сделать явное преобразование asInstanceOf[TextArea] после document.getElementById, но это логично и мелочевка.

На простых примерах работало отлично, на основном примере — подвисло аж на 45 секунд. Браузер трижды предлагал убить скрипт. Размер сборки, кстати — 1.2Мб. Вроде логично: собирал-то я в неоптимизированном варианте, через sbt fastLinkJS. Для оптимизированной сборки нужно выполнить sbt fullLinkJS. Результат оптимизации не очень впечатлил — 35 секунд, но зато размер сборки всего 253Кб.

Для сравнения — сборка и запуск с нуля обычной версии (без JS) через sbt clean + sbt run выполнится за 26 секунд, из которых чуть меньше 3 секунд будет само выполнение. Если просто запускать jar, то общее время будет 4 секунды. Тоже многовато, но с учетом числа копирований ради иммутабельности — приемлемо. Может, когда будет настроение, попробую оптимизировать.

В официальных доках пишут, что производительность Scala JS проседает в 1-3 раза по сравнению с обычным кодом. Т.е. мои 11+ раз выглядят весьма тухло.

Я вдумчиво посмотрел в свой код аж пять минут и решил поменять List на Vector, потому что у меня есть операции добавления в конец списка, хотя выбор между двумя этими СД довольно трудный (на всякий случай: скаловский Vector — это хитрый trie, а не динамический массив, как можно подумать по названию). В обычном коде стало только хуже — время возросло до 5 секунд, т.е. стало больше на треть. А вот на фронте снизилось до 6 секунд. Все равно долго, но гораздо лучше, чем 35. И, получается, медленнее обычного кода всего в полтора раза, что укладывается в диапазон 1-3 из официальных бенчмарков. Ускорение спишу на разницу работы с памятью в JVM и JS, подробности оставлю как упражнение читателю :)

Что в итоге получилось — можно посмотреть на гитхабе, рекомендую сразу на первый дифф смотреть.

P.S. по последним постам может показаться, что я мазохист и люблю копаться во фронте, но нет — просто так получилось, что хотелось попробовать, а все руки не доходили (яжбэкендер).

Term query ищет документы по точному совпадению запроса с токенами в индексе, а match query — по совпадению токенизированого запроса. Т.е. к значению в запросе применяются те же преобразования, что и при индексации, или даже какой-то другой анализатор. Дополнительная плюшка match query еще в том, что он, как и term query, универсален, и позволяет искать не только по текстовым полям, но и по keyword/числовым/датам и т.п.

Возникает вопрос: а зачем тогда вообще нужен term query? Для текстового поля логично использовать тот же анализатор (разве что кроме каких-то очень экзотических случаев или дебага). Для прочих типов полей — разница будет крошечной: потратится только немного времени на определение анализатора, который надо применить (чтобы выяснить, что его нет). Даже разработчики говорят — используйте match для единообразия. И в старом гайде пишут примерно то же самое. Я нашел только один аргумент — скоринг: в term query игнорируется IDF. Но это подходит под “экзотический случай”.

Альтернативный вариант — использовать для всего, кроме текста terms query. Это ясно дает понять, что ищем в индексе “как есть”, намекая на то, что это поле в индексе тоже хранится “как есть”.

Случайно наткнулся на сборник шпаргалок по OWASP.

Если кто вдруг не знает, OWASP (Open Web Application Security Project) — это онлайн-сообщество, которое рожает бесплатные советы про то, как безопасно писать преобразователи sql в json веб-приложения. Самое известное и старое творчество — OWASP TOP 10.

Возможно, в каких-то компаниях от круд-формошлепов старших разработчиков будут требовать знания этих рекомендаций. Правда есть нюанс — большая часть проблем, описанных в них, покрывается нормальными библиотеками/фреймворками и правилом “не реализуй безопасность самостоятельно”. А если и накосячить в этом — проверять вас скорее всего будет такой же разработчик, как и вы, потому что большинству компаний насрать на ИБ в целом, а на безопасный процесс разработки — тем более. Даже если не насрать — то должен быть как минимум специальный человек, ответственный за это, который в том числе отвечает за такие вещи, как построение модели нарушителя, обучение специалистов, организацию проверки кода на соответствие требованиям ИБ.

А сами шпаргалки среднего качества и довольно разнородны. Но пригодятся для того, чтобы проверить себя на совсем очевидные ляпы или начать погружаться в тему.

Решил попробовать на прошлой неделе, после закрытия долга с задачей про заявки.

Думаю, найду сейчас какой-нибудь туториал, пройду его и буду корпеть над составлением yaml для корректной работы.

Оказалось, что для того, чтобы подключить прогон тестов нужно просто зайти на вкладку с Actions, нажать одну кнопку для подключения

потом при желании подредактировать файлик (я заменил java 1.8 на 11) и жахнуть коммит.

Т.е. три клика и все. Я в шоке.

What a great time to be alive!