Это решается тем, что оператор индексирования должен возвращать не ссылку, а служебный объект с перегруженными операторами конвертации в char, присваивания и взятия ссылки.
И внутри этого объекта можно сделать уже создание копии при присваивании.
Объект легковесный, содержит в себе только указатель на оригинальный объект строки и запрошенный индекс, в 99% случаев компилятор должен инлайнить всё это.
Вот суть в том, что он на самом деле может выбирать далеко не только Number, если дать ему кастомный NumberPicker.Formatter.
Выглядит один в один как то что в Telegram и то что вы сделали. Разумеется, потребуется поставить 3 экземпляра NumberPicker в ряд, первому дав свой Formatter, чтобы показывать даты вместо чисел, остальным только ограничить минимальное и максимальное значение.
Цифровой зум, цифровому зуму рознь. Если это просто увеличение изображения по детерменированному алгоритму типа удвоения пикселей или взятия среднего, то это вполне имеет место быть.
Просто потому что если интересующий объект занимает несколько пикселей, то ученому придётся либо утыкаться носом в экран, либо использовать цифровой зум. Второе удобнее. На фото товара микроскоп имеет свой экран, то есть полагаться на средства ОС нельзя, надо иметь своё.
Но если такая картинка попадёт в статью, должен быть указан и метод интерполяции.
Касательно Google, полагаю, такой микроскоп предлагается использовать не учёным, а врачам, которые не исследуют рак, а лечат готовыми протоколами лечения, придуманным кем-то до них, а ИИ лишь помогает этим алгоритмам лучше следовать.
Фото с микроскопа, по-хорошему, делается не на смартфон. А у научного оборудования по ТЗ не должно быть никаких улучшайзеров. Это как снимки в RAW на зеркалках.
Перевёл недавно свой личный сервер на vicroria metrics. Прометиус жрал 300 МБ ОЗУ, Виктория 100. Прометиус жрал 300 МБ диска, Виктория 40 МБ.
Для личной дешёвой VPS разница очень ощутима (у меня всего 2 ГБ ОЗУ и 20 ГБ диск), метрики не должны жрать больше сервисов.
С другой стороны на большом проекте и метрик будет побольше, так что там тоже может быть заметна разница.
Удобно, что есть совместимость по протоколу и конфигу (кроме алертов). Можно поднять контейнер с викторией параллельно прометиусу с его же конфигом и просто посмотреть кто больше сожрёт ресурсов, например, за неделю (надо учитывать время хранения метрик для честности сравнения) и убить его.
Также я бы добавил, что секретный ключ JWT критически важно надёжно хранить и уж точно не копипастить из статьи (знание ключа позволяет генерировать jwt с ЛЮБЫМ содержанием, которые будут неотличимы от легитимных). Если очень лень реализовывать механизм конфигурации и генерировать свой ключ, можно генерировать случайный ключ при запуске приложения. Тогда, конечно, перезапуск приложения будет грохать все активные сессии, но это лучше, чем использовать чужой ключ.
На месте автора статьи, я бы вставил сниппет с генерацией при запуске.
Как реализовать функцию "выйти со всех устройств"?
Подход с чистым jwt токеном не очень безопасен, так как в случае компрометации учётной записи (это гораздо проще, чем кажется, достаточно войти через публичный компьютер и забыть выйти), пользователь ничего с этим не может сделать - полученный злоумышленником токен будет действовать как обычный.
Как я понимаю, чистый jwt имеет смысл либо совсем короткоживущий (секунды, как промежуточный ключ авторизации в каком-то более сложном процессе), либо при общении между микросервисами (когда токен полученный от пользователя уже валидирован фронтовым микросервисом каким-то stateful способом). Во всех остальных случаях он является огромной дырой.
Закрыть эту дыру можно механизмом отзыва токенов. Хранить в каком-нибудь Redis список отозванных токенов. Такая проверка будет быстрее, чем по БД.
В свою очередь в своих петах я реализую лениво просто один токен на все сессии. У юзера в БД есть колонка auth_token. Если там NULL в момент авторизации, генерирую случайную строку, кладу в БД и отдаю юзеру. Если там уже что-то есть, возвращаю то что есть. Все запросы начинаются с поиска в БД юзера по токену (это, конечно же, колонка с уникальным индексом). Выход с одного устройства осуществляется просто забыванием токена без запроса на сервер. Выход со всех устройств приводит к записи NULL в колонку токена (или можно сразу перегенерировать токен, если нам нужна функция "выйти со всех устройств, кроме текущего").
Соответственно, таким образом как и с JWT мы не плодим строчки на каждую забытую сессию и не нуждаемся в JOIN с информацией о пользователе, зато позволяем юзеру прибить все сессии в случае компрометации учётной записи.
Можно дополнительно завернуть такой токен в JWT, если хочется индивидуального времени жизни токенов. Хотя я такое не люблю, я предпочитаю сайты с вечной авторизацией (собственно, все популярные сервисы типа гугла или вконтакте авторизуют пользователя навсегда). Если хочется особой секурности, можно сделать два токена. Один вечный, другой сессионный. Все запросы идут со вторым, но если приходит ошибка 401, то через специальный эндпойнт и вечный токен, получается новый сессионный токен (таким образом мы значительно понижаем шансы при MITM, что утечет вечный токен, ибо его ещё надо поймать). Но для пета скорее всего это будет излишне, так как кража токена прямо из HTTPS маловероятна в целом.
Мне видится основными сценариями атаки либо вирус на компьютере (в таком случае следует полагать, что украдено всё - и все токены, и пароли, единственное, что может сделать пользователь - сменить пароль и воспользоваться функцией "выйти со всех устройств"), либо забыл выйти с общего компьютера (поможет только "выйти со всех устройств"). Ещё есть фишинг, но там как и в случае с вирусом без смены пароля и "выйти со всех устройств" не обойтись.
А что насчёт того, что аккумуляторы могут надуваться в процессе старения? Обычно в телефонах есть зазор под надувание, плюс на худой конец деформируются мягкие элементы корпуса.
В статье не просто используют штатное окно, но и кастомизируют его ломая инкапсуляцию напрямую модифицируя свойства внутренних окон. Это не очень надёжно, так как может сломаться на других версиях ОС и просто в каких-то особых условиях. Например, само диалоговое окно вообще ищется по заголовку, а никаких гарантий, что не будет другого окна с таким же заголовком - нет.
Тут как раз правильно либо укладываться в функционал стандартного интерфейса, либо делать своё окно. Простенькое окно с текстом и стандартным прогресс-баром будет вполне органично смотреться на любой версии Windows. Мало кто из пользователей наизусть знает все вариации диалоговых окон конкретной версии винды, тем более что у половины приложений они свои "+- похожие на системные".
Если не использовать какие-то нестандартные цвета и т. п., а оставить системные дефолты, то никто ничего не поймёт.
Полагаю, программы должны позволять стартовать игру не только с начальной позиции, но и с заданной. Так что при зависаниях и ошибках можно перезапустить программу, задав ей позицию на доске на момент зависания. Более того, в статье указано, что программу и так не гоняли непрерывно, а по ночам, так что по-любому перезапуск был штатным режимом.
Можно хранить список свободных pid и брать случайный элемент из него одновременно удаляя. А при завершении процесса класть его pid в список. Тогда генерация случайного pid может иметь O(1) ценой роста потребления памяти. Но хранить 32768 int на современном железе не проблема.
Это решается тем, что оператор индексирования должен возвращать не ссылку, а служебный объект с перегруженными операторами конвертации в char, присваивания и взятия ссылки.
И внутри этого объекта можно сделать уже создание копии при присваивании.
Объект легковесный, содержит в себе только указатель на оригинальный объект строки и запрошенный индекс, в 99% случаев компилятор должен инлайнить всё это.
https://developer.android.com/reference/android/widget/NumberPicker
Вот суть в том, что он на самом деле может выбирать далеко не только Number, если дать ему кастомный NumberPicker.Formatter.
Выглядит один в один как то что в Telegram и то что вы сделали. Разумеется, потребуется поставить 3 экземпляра NumberPicker в ряд, первому дав свой Formatter, чтобы показывать даты вместо чисел, остальным только ограничить минимальное и максимальное значение.
Цифровой зум, цифровому зуму рознь. Если это просто увеличение изображения по детерменированному алгоритму типа удвоения пикселей или взятия среднего, то это вполне имеет место быть.
Просто потому что если интересующий объект занимает несколько пикселей, то ученому придётся либо утыкаться носом в экран, либо использовать цифровой зум. Второе удобнее. На фото товара микроскоп имеет свой экран, то есть полагаться на средства ОС нельзя, надо иметь своё.
Но если такая картинка попадёт в статью, должен быть указан и метод интерполяции.
Касательно Google, полагаю, такой микроскоп предлагается использовать не учёным, а врачам, которые не исследуют рак, а лечат готовыми протоколами лечения, придуманным кем-то до них, а ИИ лишь помогает этим алгоритмам лучше следовать.
Фото с микроскопа, по-хорошему, делается не на смартфон. А у научного оборудования по ТЗ не должно быть никаких улучшайзеров. Это как снимки в RAW на зеркалках.
Исследования проходят многократную перепроверку реальностью.
Во-первых, другие учёные пытаются повторить и получить те же результаты на мышах, перенести на крыс и т. д.
Во-вторых, прежде чем лекарство выйдет на массовый рынок, оно должно пройти исследования не только на мышах, но и на людях.
На каком-то этапе статья и реальность не сойдётся. Если только не фальсифицирован последний этап клинических испытаний или вообще всё.
Надо дождаться, когда JIT будет учитывать аннотации типов при кодогенерации. Вот тогда будет совсем интересно. А пока аннотации просто отбрасываются.
Перевёл недавно свой личный сервер на vicroria metrics. Прометиус жрал 300 МБ ОЗУ, Виктория 100. Прометиус жрал 300 МБ диска, Виктория 40 МБ.
Для личной дешёвой VPS разница очень ощутима (у меня всего 2 ГБ ОЗУ и 20 ГБ диск), метрики не должны жрать больше сервисов.
С другой стороны на большом проекте и метрик будет побольше, так что там тоже может быть заметна разница.
Удобно, что есть совместимость по протоколу и конфигу (кроме алертов). Можно поднять контейнер с викторией параллельно прометиусу с его же конфигом и просто посмотреть кто больше сожрёт ресурсов, например, за неделю (надо учитывать время хранения метрик для честности сравнения) и убить его.
Очевидно, одобренные СБ флешки будут включены в белые списки устройств, чтобы политики пропускали.
Этот код не будет обрабатывать больше 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 на современном железе не проблема.