В том и дело. Роль "одноплатника" в этой схеме сводится к какому-то промежуточному драйверу. А вся ЧПУшность ушла в программу-упрощалку на ПК. То есть самостоятельного ЧПУ на 155-й серии тут не получилось.
Одни и те же требования, серьёзно? Вот у вас дома холодильник стоит. Вы его с собой таскаете или всё-таки ключ от замка в том доме у вас в кармане лежит? Точно так же и KMS для генерации/хранения/удаления криптоключей - она сильно проще, дешевле и легче, чем СУБД с кучей фичей под кучу типов данных с тем же уровнем предсказуемого стирания.
Как это не поможет? Новая сессия запустится уже с новыми кодами. Сколько таких сессий придётся создать чтобы в одной из них код совпал с тем, который подставляет атакующий? Это что-то вроде подбора в случайном порядке. В чистом виде это уязвимо, но в рамках сессии проще тормозить перебор и противодействовать перехвату логина (когда юзер вводит верный пароль, а атакующий с другого клиента перебирает OTP). Поэтому добавляем сюда задержку проверки на пару секунд, предотвращаем параллельные сессии, и всё. Это уже далеко от тривиального перебора 4-6-значных кодов. Поверх этого базового механизма уже прикручивается вторичная защита: рейт лимит по айпи, локаут, капча и алерты админам.
Не вижу принципиальных проблем держать свой ключ на каждую строку или перешифровывать всю колонку единым ключом кроме удаляемой ячейки (можно оптимизировать пакетированием - делать раз в сутки, например). Практичность будет определяться требованиями к надёжному удалению в том числе.
Сохраняйте в зашифрованном виде. При необходимости удалить просто "выкидывайте" ключ для расшифровки вместе с удалением данных. Тогда задача хотя бы сводится к надёжному хранению и удалению ключей.
В 2018 точно так же поставил тиндер от одиночества. Никто ничего противозаконного не предлагал и на ужинах не наглел. С нескольких попыток (свиданий) встретил там свою нынешнюю жену. Сейчас четыре года в браке, дочь, ипотека, все дела.
У нас какие-то разные in-memory бд, потому что в моём случае она такая же полноценная, как и на диске. То есть я под этим не подразумевал какую-то куцую базу. Точно так же запускаю на ней любые запросы.
Уровни тестов с точки зрения внепроцессных зависимостей
Чёткие критерии разделения уровней тестов есть у Владимира Хорикова в прекрасной книге «Принципы Unit-тестирования»
Вот уж не знаю. Мне кажется, что разумнее делить уровни тестов по границам тестируемого поведения, а не по зависимостям. Тестируете поведение одного юнита - значит, это юнит-тест. Тестируете несколько своих юнитов вместе - интеграционный тест.
То, что в тесте затрагивается внепроцессная зависимость юнита, это всего лишь нюанс с некоторыми последствиями (задержки пуска, шум в результатах если зависимость сбоит; нестабильные тесты если зависимость некорректно сбрасывается и т.д.). Причём тормоза могут быть вполне приемлемы в ряде случаев. В конце концов, поведение это вполне себе атрибут юнита, а процесс это пятью этажами выше. Или вообще на другой улице.
Как вы тестируете сервисы, использующие СУБД?
Поднимаем in-memory базу.
Как изолируете тестовые сценарии, влияющие на базу данных?
Не припомню ни одного проекта за последние несколько лет, где бы линтер не был включен "на стадии котлована". Причём с одинаковыми настройками как в редакторах у разрабов, так и в пайплайнах.
По юнит-тестам на текущем моём проекте (с 2023) покрытие 96%. На предыдущем (с 2020) было в районе 80.
Линтеры и высокое покрытие автотестами это лишь база, за пределами которой только начинается ревью. И это я ещё в обычной заказной разработке занят.
Когда пойдешь искать работу то в резюме "был на фрилансе с 2012 по 2015" считается за ноль
Пфф. Если речь именно про резюме, а не про выписку из трудовой для кадровика госпредприятия, то этот опыт эквивалентен работе на студию - в таком свете это и можно представить, "2012-2015 студия moooV, различные заказчики".
В том и дело. Роль "одноплатника" в этой схеме сводится к какому-то промежуточному драйверу. А вся ЧПУшность ушла в программу-упрощалку на ПК. То есть самостоятельного ЧПУ на 155-й серии тут не получилось.
Зачем релокантам рустор?
Чтобы на таком зарабатывать 300к/мес, нужно три раза в час воровать и перепродавать все заказы в течение месяца.
Может, так и считали? Курьер не принёс заказ, а обиженный журналист экстраполировал это на целый месяц?
Одни и те же требования, серьёзно? Вот у вас дома холодильник стоит. Вы его с собой таскаете или всё-таки ключ от замка в том доме у вас в кармане лежит? Точно так же и KMS для генерации/хранения/удаления криптоключей - она сильно проще, дешевле и легче, чем СУБД с кучей фичей под кучу типов данных с тем же уровнем предсказуемого стирания.
Вот, нашёл заметку о cryptographic erasure, где пишут, что большие корпорации уже используют такой подход: https://www.techtarget.com/searchcloudcomputing/feature/How-Azure-AWS-Google-handle-data-destruction-in-the-cloud
Как это не поможет? Новая сессия запустится уже с новыми кодами. Сколько таких сессий придётся создать чтобы в одной из них код совпал с тем, который подставляет атакующий? Это что-то вроде подбора в случайном порядке. В чистом виде это уязвимо, но в рамках сессии проще тормозить перебор и противодействовать перехвату логина (когда юзер вводит верный пароль, а атакующий с другого клиента перебирает OTP). Поэтому добавляем сюда задержку проверки на пару секунд, предотвращаем параллельные сессии, и всё. Это уже далеко от тривиального перебора 4-6-значных кодов. Поверх этого базового механизма уже прикручивается вторичная защита: рейт лимит по айпи, локаут, капча и алерты админам.
Кузовные мастерские появились вместе с автомобилями. Вместе с ними и будут развиваться.
Не вижу принципиальных проблем держать свой ключ на каждую строку или перешифровывать всю колонку единым ключом кроме удаляемой ячейки (можно оптимизировать пакетированием - делать раз в сутки, например). Практичность будет определяться требованиями к надёжному удалению в том числе.
Кто так OTP делает вообще? Там сессия должна быть, в рамках которой даётся несколько попыток.
Сохраняйте в зашифрованном виде. При необходимости удалить просто "выкидывайте" ключ для расшифровки вместе с удалением данных. Тогда задача хотя бы сводится к надёжному хранению и удалению ключей.
В экосистеме .NET такой фиче уже сто лет в обед (Blazor), но что-то крупные игроки не спешат её использовать.
Угу, как средство поднять рождаемость даже. Хотя, казалось бы, изначальная идея приложения - переспать без обязательств. Развели как лоха, гады.
В 2018 точно так же поставил тиндер от одиночества. Никто ничего противозаконного не предлагал и на ужинах не наглел. С нескольких попыток (свиданий) встретил там свою нынешнюю жену. Сейчас четыре года в браке, дочь, ипотека, все дела.
У нас какие-то разные in-memory бд, потому что в моём случае она такая же полноценная, как и на диске. То есть я под этим не подразумевал какую-то куцую базу. Точно так же запускаю на ней любые запросы.
Вот уж не знаю. Мне кажется, что разумнее делить уровни тестов по границам тестируемого поведения, а не по зависимостям. Тестируете поведение одного юнита - значит, это юнит-тест. Тестируете несколько своих юнитов вместе - интеграционный тест.
То, что в тесте затрагивается внепроцессная зависимость юнита, это всего лишь нюанс с некоторыми последствиями (задержки пуска, шум в результатах если зависимость сбоит; нестабильные тесты если зависимость некорректно сбрасывается и т.д.). Причём тормоза могут быть вполне приемлемы в ряде случаев. В конце концов, поведение это вполне себе атрибут юнита, а процесс это пятью этажами выше. Или вообще на другой улице.
Поднимаем in-memory базу.
Чистим часть таблиц между сценариями.
Работает замечательно.
Зачем в 2024 году ставить порт для аналоговых мониторов? Лучшего применения этому месту на корпусе не нашлось? Он ещё и торчит в отличие от остальных.
Почему ugly всюду переводят "уродливый" когда в таком контексте куда уместнее "страшный"?
Шта?
Не припомню ни одного проекта за последние несколько лет, где бы линтер не был включен "на стадии котлована". Причём с одинаковыми настройками как в редакторах у разрабов, так и в пайплайнах.
По юнит-тестам на текущем моём проекте (с 2023) покрытие 96%. На предыдущем (с 2020) было в районе 80.
Линтеры и высокое покрытие автотестами это лишь база, за пределами которой только начинается ревью. И это я ещё в обычной заказной разработке занят.
Почему именно в РФ? Врубил впн, открыл амазон, крутанул страницу легоченько.
Пфф. Если речь именно про резюме, а не про выписку из трудовой для кадровика госпредприятия, то этот опыт эквивалентен работе на студию - в таком свете это и можно представить, "2012-2015 студия moooV, различные заказчики".