Если "научного" объяснения на Западе не нашли - значит, оно просто никому не выгодно. И я не совсем понимаю, зачем вы защищаете порнографию? Это уже считается чем-то нормальным среди взрослых (не говоря про молодежь)? Люди прибегают к этому средству по разным причинам, но долгое его применение явно не приведет ни к чему хорошему, никаких научных исследований тут не надо - достаточно здравого смысла
Интересная статья, спасибо. Я об этом не думал в таком научном ключе, но сейчас пришел к выводу, что такой механизм выглядит правдоподобно. Когда меня интересует какая-то рабочая задача (или даже задача, которой занимаюсь в свободное время из интереса), мне не требуются игры/сериалы/т.д., и наоборот - стоит начать играть/смотреть что-то, как пропадает всякое желание заниматься даже самой интересной задачей. Как будто этот самый абстрактный интерес расходуется, в результате чего ты делаешь только что-то одно
Одна из причин использовать UUID - ID на основе монотонно возрастающих последовательностей легко перебирать, из-за чего можно искать "уязвимые" ресурсы (через REST API, например)
6 где-то пару лет, в минимальной конфигурации, все устраивает. Иногда бывают приколы с большими обновлениями ОС, но меня полностью устраивает - производительность норм (128 диск), хороший дисплей, чистая система (хотя гугл свои приложения "ставит" периодически), заряд пока ещё день где-то держит
Похоже на маркер, но скорее организации разработки, чем архитектуры - в микросервисах любой общий код становится проблемой на всех уровнях, в том числе на уровне сборки. Просто кататься на микросервисах санках хочется, а таскать их - нет, ничего нового
Подумал второй раз и кажется, что по безопасности одно и то же. Во всяком случае СМС показал себя как небезопасный метод аутентификации (старый стандарт, не проектировался для этих целей, подвержен социальной инженерии как с точки зрения оператора связи, так и конечных пользователей, были проблемы с шифрованием). А насколько сложно узнать, кто тебе звонит, ничего не могу сказать - возможно это так же легко можно сделать. Вообще есть ощущение, что эти приколы с операторами связи не являются безопасной аутентификацией, если они не были изначально спроектированы для этого. Про аутентификацию по исходящему звонку слышу впервые, звучит как ужас)
Вы не звоните - вам звонят. Звонок принимать не надо - достаточно четыре последние цифры ввести в приложении/на сайте. С безопасностью лучше, чем у СМС, но вот если у тебя дома связи не ловит (как у меня) - такие способы дополнительной аутентификации становятся головной болью.
Я не фронтенд, только пишу свое приложение с фронтом и как-то получилось, что пишу на web components (через Lit). Я так понимаю, что web components хороши для дизайн-систем - создания каких-то базовых компонентов, которые снаружи стилизовать почти невозможно. В частности, нельзя адекватно какие-нибудь иконки прикрутить через внешний CSS. То есть, видимо, для создания приложений надо использовать комбинацию web components (для всяких примитивов - кнопок/табов/прочего) и фреймворка (для компонентов с бизнес-логикой)?
Статья позиционируется как рассуждение о производительности серверов, основанных на разных подходах, и, вероятно, автор допустил ошибки в рассуждениях о реактивщине. Другое дело, что кроме пары сектантов её никто и не понимает - у людей достаточно проблем с бизнес логикой, а тут у тебя ещё какие-то кросс-функциональные вещи повсюду в коде
О каком состоянии речь? Если данные аутентификации на бэке это состояние, то и БД это состояние? Есть first-party аутентификация (как в вашем случае), с конкретными требованиями (возможность разлогина, таймауты, возможность посмотреть сколько у тебя сессий активных и т.д.). Есть third-party аутентификация (для этого придумали OAuth и JWT), с конкретными требованиями (делегирования доступа одних приложений к данным пользователей в других). JWT это инструмент, решающий другие задачи, противоположные вашей. Я считаю, что ваша статья приносит больше вреда, чем пользы, потому что люди прочитают ее и будут дальше придумывать собственные алгоритмы аутентификации, что чревато. Секьюрити один из тех случаев, где лучше всегда взять готовое, если оно есть
Работаю с YC уже некоторое время и меня смущает взаимодействие каталогов с некоторыми сервисами. Допустим, если приложение развернуто так, что каждое окружение (dev/stage/prod) в отдельном каталоге, то условный Container Registry (который по идее один на все окружения) хранить в отдельном каталоге?
Массовые сервисы спасет (на сегодняшний день) только принудительная двухфакторная аутентификация для всех пользователей без исключения и мы уже видим, что это работает - например в Steam.
Двухфакторка - не панацея от проблем аутентификации. Кроме того, она прибавляет UX-сложности, как следствие люди будут находить способы обойти эти сложности костылями, что приведёт к меньшей безопасности чем сейчас
Достаточно часто необходимо организовать аутентификацию внешнего сервиса в нашем (логин/пароль, сертификат или токен). Для этого, в большинстве случаев, достаточно одного фильтра, который организует всю необходимую функциональность (без завязки на Spring Security), но «Spring-разработчики» упорно следуют шаблону*: если нужна безопасность - подключаем Spring Security, работа с БД — Spring Data JPA, микросервисы – Spring Cloud.
Суть примеров ясно, но я бы поостерёгся упоминать Spring Security в этом примере. Придумывать свои решения в области безопасности, просто чтобы не пользоваться решением из фреймворком (которое скорее всего протестировано, проревьюено специалистами в области безопасности и т.д.) может быть чревато. Тем более что тот же Spring Security автоматом применяет средства защиты от некоторых уязвимостей (например, в StrictHttpFirewall)
Некорректный пример. С его помощью можно выставить любую попытку улучшить что угодно бессмысленной с точки зрения «Можно хотя бы попробовать уменьшить число потенциальных травм»
Устроит, если подробно опишите механизм стимуляции к сексу через постоянный просмотр порнографии. Я теперь до утра не усну, слишком интересно
Я секс не упоминал, речь шла только про порнографию
Если "научного" объяснения на Западе не нашли - значит, оно просто никому не выгодно.
И я не совсем понимаю, зачем вы защищаете порнографию? Это уже считается чем-то нормальным среди взрослых (не говоря про молодежь)? Люди прибегают к этому средству по разным причинам, но долгое его применение явно не приведет ни к чему хорошему, никаких научных исследований тут не надо - достаточно здравого смысла
Интересная статья, спасибо. Я об этом не думал в таком научном ключе, но сейчас пришел к выводу, что такой механизм выглядит правдоподобно. Когда меня интересует какая-то рабочая задача (или даже задача, которой занимаюсь в свободное время из интереса), мне не требуются игры/сериалы/т.д., и наоборот - стоит начать играть/смотреть что-то, как пропадает всякое желание заниматься даже самой интересной задачей. Как будто этот самый абстрактный интерес расходуется, в результате чего ты делаешь только что-то одно
Скрин из Galaxy on fire 2, будто переместился лет на 15 назад
Одна из причин использовать UUID - ID на основе монотонно возрастающих последовательностей легко перебирать, из-за чего можно искать "уязвимые" ресурсы (через REST API, например)
6 где-то пару лет, в минимальной конфигурации, все устраивает. Иногда бывают приколы с большими обновлениями ОС, но меня полностью устраивает - производительность норм (128 диск), хороший дисплей, чистая система (хотя гугл свои приложения "ставит" периодически), заряд пока ещё день где-то держит
Похоже на маркер, но скорее организации разработки, чем архитектуры - в микросервисах любой общий код становится проблемой на всех уровнях, в том числе на уровне сборки. Просто кататься на микросервисах санках хочется, а таскать их - нет, ничего нового
Подумал второй раз и кажется, что по безопасности одно и то же. Во всяком случае СМС показал себя как небезопасный метод аутентификации (старый стандарт, не проектировался для этих целей, подвержен социальной инженерии как с точки зрения оператора связи, так и конечных пользователей, были проблемы с шифрованием). А насколько сложно узнать, кто тебе звонит, ничего не могу сказать - возможно это так же легко можно сделать.
Вообще есть ощущение, что эти приколы с операторами связи не являются безопасной аутентификацией, если они не были изначально спроектированы для этого.
Про аутентификацию по исходящему звонку слышу впервые, звучит как ужас)
Вы не звоните - вам звонят. Звонок принимать не надо - достаточно четыре последние цифры ввести в приложении/на сайте.
С безопасностью лучше, чем у СМС, но вот если у тебя дома связи не ловит (как у меня) - такие способы дополнительной аутентификации становятся головной болью.
Я не фронтенд, только пишу свое приложение с фронтом и как-то получилось, что пишу на web components (через Lit). Я так понимаю, что web components хороши для дизайн-систем - создания каких-то базовых компонентов, которые снаружи стилизовать почти невозможно. В частности, нельзя адекватно какие-нибудь иконки прикрутить через внешний CSS. То есть, видимо, для создания приложений надо использовать комбинацию web components (для всяких примитивов - кнопок/табов/прочего) и фреймворка (для компонентов с бизнес-логикой)?
Не могу проголосовать кармой, так что поблагодарю комментарием. Хорошая формализация, в целом со всем согласен, интересно узнать, что дальше
Режете по живому
Статья позиционируется как рассуждение о производительности серверов, основанных на разных подходах, и, вероятно, автор допустил ошибки в рассуждениях о реактивщине. Другое дело, что кроме пары сектантов её никто и не понимает - у людей достаточно проблем с бизнес логикой, а тут у тебя ещё какие-то кросс-функциональные вещи повсюду в коде
Да, конечно, извиняюсь. В любом случае обращался к автору
О каком состоянии речь? Если данные аутентификации на бэке это состояние, то и БД это состояние?
Есть first-party аутентификация (как в вашем случае), с конкретными требованиями (возможность разлогина, таймауты, возможность посмотреть сколько у тебя сессий активных и т.д.). Есть third-party аутентификация (для этого придумали OAuth и JWT), с конкретными требованиями (делегирования доступа одних приложений к данным пользователей в других). JWT это инструмент, решающий другие задачи, противоположные вашей.
Я считаю, что ваша статья приносит больше вреда, чем пользы, потому что люди прочитают ее и будут дальше придумывать собственные алгоритмы аутентификации, что чревато. Секьюрити один из тех случаев, где лучше всегда взять готовое, если оно есть
Работаю с YC уже некоторое время и меня смущает взаимодействие каталогов с некоторыми сервисами. Допустим, если приложение развернуто так, что каждое окружение (dev/stage/prod) в отдельном каталоге, то условный Container Registry (который по идее один на все окружения) хранить в отдельном каталоге?
Двухфакторка - не панацея от проблем аутентификации. Кроме того, она прибавляет UX-сложности, как следствие люди будут находить способы обойти эти сложности костылями, что приведёт к меньшей безопасности чем сейчас
Суть примеров ясно, но я бы поостерёгся упоминать Spring Security в этом примере. Придумывать свои решения в области безопасности, просто чтобы не пользоваться решением из фреймворком (которое скорее всего протестировано, проревьюено специалистами в области безопасности и т.д.) может быть чревато. Тем более что тот же Spring Security автоматом применяет средства защиты от некоторых уязвимостей (например, в
StrictHttpFirewall)