Также я бы добавил, что секретный ключ JWT критически важно надёжно хранить и уж точно не копипастить из статьи (знание ключа позволяет генерировать jwt с ЛЮБЫМ содержанием, которые будут неотличимы от легитимных). Если очень лень реализовывать механизм конфигурации и генерировать свой ключ, можно генерировать случайный ключ при запуске приложения. Тогда, конечно, перезапуск приложения будет грохать все активные сессии, но это лучше, чем использовать чужой ключ.
На месте автора статьи, я бы вставил сниппет с генерацией при запуске.
Как реализовать функцию "выйти со всех устройств"?
Подход с чистым jwt токеном не очень безопасен, так как в случае компрометации учётной записи (это гораздо проще, чем кажется, достаточно войти через публичный компьютер и забыть выйти), пользователь ничего с этим не может сделать - полученный злоумышленником токен будет действовать как обычный.
Как я понимаю, чистый jwt имеет смысл либо совсем короткоживущий (секунды, как промежуточный ключ авторизации в каком-то более сложном процессе), либо при общении между микросервисами (когда токен полученный от пользователя уже валидирован фронтовым микросервисом каким-то stateful способом). Во всех остальных случаях он является огромной дырой.
Закрыть эту дыру можно механизмом отзыва токенов. Хранить в каком-нибудь Redis список отозванных токенов. Такая проверка будет быстрее, чем по БД.
В свою очередь в своих петах я реализую лениво просто один токен на все сессии. У юзера в БД есть колонка auth_token. Если там NULL в момент авторизации, генерирую случайную строку, кладу в БД и отдаю юзеру. Если там уже что-то есть, возвращаю то что есть. Все запросы начинаются с поиска в БД юзера по токену (это, конечно же, колонка с уникальным индексом). Выход с одного устройства осуществляется просто забыванием токена без запроса на сервер. Выход со всех устройств приводит к записи NULL в колонку токена (или можно сразу перегенерировать токен, если нам нужна функция "выйти со всех устройств, кроме текущего").
Соответственно, таким образом как и с JWT мы не плодим строчки на каждую забытую сессию и не нуждаемся в JOIN с информацией о пользователе, зато позволяем юзеру прибить все сессии в случае компрометации учётной записи.
Можно дополнительно завернуть такой токен в JWT, если хочется индивидуального времени жизни токенов. Хотя я такое не люблю, я предпочитаю сайты с вечной авторизацией (собственно, все популярные сервисы типа гугла или вконтакте авторизуют пользователя навсегда). Если хочется особой секурности, можно сделать два токена. Один вечный, другой сессионный. Все запросы идут со вторым, но если приходит ошибка 401, то через специальный эндпойнт и вечный токен, получается новый сессионный токен (таким образом мы значительно понижаем шансы при MITM, что утечет вечный токен, ибо его ещё надо поймать). Но для пета скорее всего это будет излишне, так как кража токена прямо из HTTPS маловероятна в целом.
Мне видится основными сценариями атаки либо вирус на компьютере (в таком случае следует полагать, что украдено всё - и все токены, и пароли, единственное, что может сделать пользователь - сменить пароль и воспользоваться функцией "выйти со всех устройств"), либо забыл выйти с общего компьютера (поможет только "выйти со всех устройств"). Ещё есть фишинг, но там как и в случае с вирусом без смены пароля и "выйти со всех устройств" не обойтись.
А что насчёт того, что аккумуляторы могут надуваться в процессе старения? Обычно в телефонах есть зазор под надувание, плюс на худой конец деформируются мягкие элементы корпуса.
В статье не просто используют штатное окно, но и кастомизируют его ломая инкапсуляцию напрямую модифицируя свойства внутренних окон. Это не очень надёжно, так как может сломаться на других версиях ОС и просто в каких-то особых условиях. Например, само диалоговое окно вообще ищется по заголовку, а никаких гарантий, что не будет другого окна с таким же заголовком - нет.
Тут как раз правильно либо укладываться в функционал стандартного интерфейса, либо делать своё окно. Простенькое окно с текстом и стандартным прогресс-баром будет вполне органично смотреться на любой версии Windows. Мало кто из пользователей наизусть знает все вариации диалоговых окон конкретной версии винды, тем более что у половины приложений они свои "+- похожие на системные".
Если не использовать какие-то нестандартные цвета и т. п., а оставить системные дефолты, то никто ничего не поймёт.
Полагаю, программы должны позволять стартовать игру не только с начальной позиции, но и с заданной. Так что при зависаниях и ошибках можно перезапустить программу, задав ей позицию на доске на момент зависания. Более того, в статье указано, что программу и так не гоняли непрерывно, а по ночам, так что по-любому перезапуск был штатным режимом.
Можно хранить список свободных pid и брать случайный элемент из него одновременно удаляя. А при завершении процесса класть его pid в список. Тогда генерация случайного pid может иметь O(1) ценой роста потребления памяти. Но хранить 32768 int на современном железе не проблема.
Многие проблемы решаются простым человеческим общением. Надо общаться с другими айтишниками, причём именно из той категории, которая получает пресловутые 300кк/нсек. На базе общих интересов (тут обычно нет проблем, как минимум у вас есть это самое айти), каких-то общих ценностей не связанных с деньгами (вы то ещё не вкатились). А дальше будет эффект адаптации к социальной группе. Как в эксперименте с чёрными и белыми пирамидками, только здесь вопросом будет "ваши зарплатные ожидания?" на собеседовании. Также в таком сообществе и методики вката/курсы подскажут и т. п.
В моём случае путь вката в айти такой:
Самостоятельное изучение айти потому что интересно
Вкат в стагнирующий OpenSource проект с российской аудиторией и большой флудилкой в Telegram
Рассвет разработки и смерть проекта
Я в окружён айтишниками в чатах, которые восхищаются хардскиллами, но жёстко критикуют работы с плохими условиями и ты чувствуешь, что и тебя забуллят, если на такую устроишься (причём чисто за то что не потребовал нормальную зарплату, за хардскиллы всё так же признание и восхищение)
В 2019 я нашёл свою первую полностью удалённую работу на 100к в месяц сидя в Астрахани (попутно потроллив на собеседовании местную компанию, которая попыталась продавить меня на 70к в месяц с "перспективой" роста - а всё потому что чат в Интернете ощущался более сильной реальностью, чем то что говорит собеседующий)
Спустя 3 года я получаю те самые 300к+/месяц. Другие обитатели чата тоже вышли на такой доход (но в чате появляются периодически новые участники).
Считаю, что важным фактором является то что чат неформальный неформальных людей. То есть там без сомнений делятся своими зарплатами (кто-то выпендривается, кто-то загоняется - разные мотивы), профессиональными знаниями и т. д.
Например, для realloc не указано будет ли дополнительная память инициализирована нулями или нет, допущена утечка памяти в примере кода обработки ошибок.
Вот здесь возникает проблема из-за отсутствия дженериков. Либо придётся сводить всё к void* (что теряет другую, не менее важную информацию о типе - чтобы не отправить нечаянно в strlen int*), либо для каждого типа делать парный not null тип руками.
Для smart ptr нужны деструкторы. Их нет в стандарте.
Для option/either/maybe нужны дженерики. Си может предложить только макросы (_Generic в Си это не те дженерики, которые вы ищите), которые вовсе не факт, что добавят читаемости и отлаживаемости коду.
Этот код не будет обрабатывать больше 4 одновременно подключенных клиентов.
Вам намекают использовать async.
Также я бы добавил, что секретный ключ JWT критически важно надёжно хранить и уж точно не копипастить из статьи (знание ключа позволяет генерировать jwt с ЛЮБЫМ содержанием, которые будут неотличимы от легитимных). Если очень лень реализовывать механизм конфигурации и генерировать свой ключ, можно генерировать случайный ключ при запуске приложения. Тогда, конечно, перезапуск приложения будет грохать все активные сессии, но это лучше, чем использовать чужой ключ.
На месте автора статьи, я бы вставил сниппет с генерацией при запуске.
Как реализовать функцию "выйти со всех устройств"?
Подход с чистым jwt токеном не очень безопасен, так как в случае компрометации учётной записи (это гораздо проще, чем кажется, достаточно войти через публичный компьютер и забыть выйти), пользователь ничего с этим не может сделать - полученный злоумышленником токен будет действовать как обычный.
Как я понимаю, чистый jwt имеет смысл либо совсем короткоживущий (секунды, как промежуточный ключ авторизации в каком-то более сложном процессе), либо при общении между микросервисами (когда токен полученный от пользователя уже валидирован фронтовым микросервисом каким-то stateful способом). Во всех остальных случаях он является огромной дырой.
Закрыть эту дыру можно механизмом отзыва токенов. Хранить в каком-нибудь Redis список отозванных токенов. Такая проверка будет быстрее, чем по БД.
В свою очередь в своих петах я реализую лениво просто один токен на все сессии. У юзера в БД есть колонка auth_token. Если там NULL в момент авторизации, генерирую случайную строку, кладу в БД и отдаю юзеру. Если там уже что-то есть, возвращаю то что есть. Все запросы начинаются с поиска в БД юзера по токену (это, конечно же, колонка с уникальным индексом). Выход с одного устройства осуществляется просто забыванием токена без запроса на сервер. Выход со всех устройств приводит к записи NULL в колонку токена (или можно сразу перегенерировать токен, если нам нужна функция "выйти со всех устройств, кроме текущего").
Соответственно, таким образом как и с JWT мы не плодим строчки на каждую забытую сессию и не нуждаемся в JOIN с информацией о пользователе, зато позволяем юзеру прибить все сессии в случае компрометации учётной записи.
Можно дополнительно завернуть такой токен в JWT, если хочется индивидуального времени жизни токенов. Хотя я такое не люблю, я предпочитаю сайты с вечной авторизацией (собственно, все популярные сервисы типа гугла или вконтакте авторизуют пользователя навсегда). Если хочется особой секурности, можно сделать два токена. Один вечный, другой сессионный. Все запросы идут со вторым, но если приходит ошибка 401, то через специальный эндпойнт и вечный токен, получается новый сессионный токен (таким образом мы значительно понижаем шансы при MITM, что утечет вечный токен, ибо его ещё надо поймать). Но для пета скорее всего это будет излишне, так как кража токена прямо из HTTPS маловероятна в целом.
Мне видится основными сценариями атаки либо вирус на компьютере (в таком случае следует полагать, что украдено всё - и все токены, и пароли, единственное, что может сделать пользователь - сменить пароль и воспользоваться функцией "выйти со всех устройств"), либо забыл выйти с общего компьютера (поможет только "выйти со всех устройств"). Ещё есть фишинг, но там как и в случае с вирусом без смены пароля и "выйти со всех устройств" не обойтись.
В некоторых странах для кредитов банк обязан писать в договоре крупным и заметным шрифтом уже посчитанную полную сумму переплаты.
Точно также можно обязать операторов писать полную сумму, которую пользователь выплатит за два года, а рядом рыночную стоимость телефона.
А что насчёт того, что аккумуляторы могут надуваться в процессе старения? Обычно в телефонах есть зазор под надувание, плюс на худой конец деформируются мягкие элементы корпуса.
А здесь аккумулятор в негибком стальном корпусе.
В статье не просто используют штатное окно, но и кастомизируют его ломая инкапсуляцию напрямую модифицируя свойства внутренних окон. Это не очень надёжно, так как может сломаться на других версиях ОС и просто в каких-то особых условиях. Например, само диалоговое окно вообще ищется по заголовку, а никаких гарантий, что не будет другого окна с таким же заголовком - нет.
Тут как раз правильно либо укладываться в функционал стандартного интерфейса, либо делать своё окно. Простенькое окно с текстом и стандартным прогресс-баром будет вполне органично смотреться на любой версии Windows. Мало кто из пользователей наизусть знает все вариации диалоговых окон конкретной версии винды, тем более что у половины приложений они свои "+- похожие на системные".
Если не использовать какие-то нестандартные цвета и т. п., а оставить системные дефолты, то никто ничего не поймёт.
С учётом всех переделок, не проще ли создать окно полностью вручную через WinAPI? Оно не такое уж сложное.
Ну и исходный поиск окна по заголовку выглядит костылем, так как вдруг есть другие, не наши, окна с таким заголовком.
Ещё надо умысел доказать. Потому что баги добавляющие уязвимости находят регулярно. Вопрос тут как отличить ошибку от умысла.
Полагаю, программы должны позволять стартовать игру не только с начальной позиции, но и с заданной. Так что при зависаниях и ошибках можно перезапустить программу, задав ей позицию на доске на момент зависания. Более того, в статье указано, что программу и так не гоняли непрерывно, а по ночам, так что по-любому перезапуск был штатным режимом.
Интересно посмотреть на перехваченную картинку, что именно перехватили. И что было в оригинале на экране.
Если отправитель так активно не хочет, чтобы ему вернули его деньги, зачем ему их возвращать? Пусть сам бегает суетиться.
Можно хранить список свободных pid и брать случайный элемент из него одновременно удаляя. А при завершении процесса класть его pid в список. Тогда генерация случайного pid может иметь O(1) ценой роста потребления памяти. Но хранить 32768 int на современном железе не проблема.
https://en.m.wikipedia.org/wiki/PRL-8-53
Есть вот такая штука якобы улучшающая запоминание как раз у здоровых людей. Правда, на Википедии описан только один эксперимент и в прошлом веке.
Многие проблемы решаются простым человеческим общением. Надо общаться с другими айтишниками, причём именно из той категории, которая получает пресловутые 300кк/нсек. На базе общих интересов (тут обычно нет проблем, как минимум у вас есть это самое айти), каких-то общих ценностей не связанных с деньгами (вы то ещё не вкатились). А дальше будет эффект адаптации к социальной группе. Как в эксперименте с чёрными и белыми пирамидками, только здесь вопросом будет "ваши зарплатные ожидания?" на собеседовании. Также в таком сообществе и методики вката/курсы подскажут и т. п.
В моём случае путь вката в айти такой:
Самостоятельное изучение айти потому что интересно
Вкат в стагнирующий OpenSource проект с российской аудиторией и большой флудилкой в Telegram
Рассвет разработки и смерть проекта
Я в окружён айтишниками в чатах, которые восхищаются хардскиллами, но жёстко критикуют работы с плохими условиями и ты чувствуешь, что и тебя забуллят, если на такую устроишься (причём чисто за то что не потребовал нормальную зарплату, за хардскиллы всё так же признание и восхищение)
В 2019 я нашёл свою первую полностью удалённую работу на 100к в месяц сидя в Астрахани (попутно потроллив на собеседовании местную компанию, которая попыталась продавить меня на 70к в месяц с "перспективой" роста - а всё потому что чат в Интернете ощущался более сильной реальностью, чем то что говорит собеседующий)
Спустя 3 года я получаю те самые 300к+/месяц. Другие обитатели чата тоже вышли на такой доход (но в чате появляются периодически новые участники).
Считаю, что важным фактором является то что чат неформальный неформальных людей. То есть там без сомнений делятся своими зарплатами (кто-то выпендривается, кто-то загоняется - разные мотивы), профессиональными знаниями и т. д.
Очень поверхностно.
Например, для realloc не указано будет ли дополнительная память инициализирована нулями или нет, допущена утечка памяти в примере кода обработки ошибок.
Ещё есть каппа-опиодные рецепторы антагонизм которых подавляет дисфорический компонент стресса. Тоже очень перспективно выглядит.
Что в
not_null_ptrлежит? void*? char*?Вот здесь возникает проблема из-за отсутствия дженериков. Либо придётся сводить всё к void* (что теряет другую, не менее важную информацию о типе - чтобы не отправить нечаянно в strlen int*), либо для каждого типа делать парный not null тип руками.
Для smart ptr нужны деструкторы. Их нет в стандарте.
Для option/either/maybe нужны дженерики. Си может предложить только макросы (_Generic в Си это не те дженерики, которые вы ищите), которые вовсе не факт, что добавят читаемости и отлаживаемости коду.
В истории из статьи автор залетел один раз 18 лет назад
Так никто вам справку об этом не принесёт