И правдо сработало. Жаль только радовался я рано - сервер перегружен, в консоли полно 429 ошибок от их sentry, и на любой запрос бот отваливается по таймауту...
С паролем может быть еще хуже, из личного опыта. В проекте которым сейчас занимаюсь случайно получилось так что при восстановлении пароля в базу писался чистый пароль а не его хэш (что, соответственно, означало что A) пользователь не смог-бы войти сменив пароль, и B) было потенциальной уязвимостью), к счастью наш доблестный QA это увидел до выкатки. Как это получилось? Как оказалось, когда все три (инпут с фронта, хэш этого инпута, и хэшированный пароль из базы) все имеют сигнатуру `smthPassword: String` - весьма несложно случайно запихнуть не то значение не в то поле по невнимательности. Решилась проблема использованием тонкой newtype обертки HashedPassword(String), благодаря которой теперь нельзя запихнуть "сырой" пароль String в поле (или функцию) тип которого HashedString, нельзя по-незнанию/наивности сравнить хэш и сырой пароль напрямую, нельзя случайно вывести пароль (точнее его хэш) из микро-сервиса через RPC или записать его в лог, ибо ждя этого типа соответствующие фичи не имплементированы за ненадобностью, etc.
В том что касается первого примера с email - нужно, конечно, подходить к этому без фанатизма, но тем не менее между
//if user.email_verified { // ой, забыл/не знал что такое поле вообще есть
send_sensitive_data_to(user.email);
//}
и
enum UserEmail {
NotVerified { email: String },
Verified { email: String },
}
// send_sensitive_data_to(user.email);
// нельзя, ибо send_sensitive_data_to() ждет строку, а тут какой-то UserEmail
// send_sensitive_data_to(user.email.email);
// нельзя, ибо такое поле есть только у конкретных вариантов а не у всего типа
match user.email {
NotVerified { email: not_verified_email } => send_sensitive_data_to(not_verified_email);
//...
}
второй вариант выглядит куда более надежным, так как когда ты не можешь использовать email напрямую (при условии, конечно, что в языке есть средства позволяющие это сделать, как например enum в Rust или closed/sealed типы в Haskell/Scala) и должен руками написать что ты хочешь отправить секретную инфу на конкретно непроверенный email - явно большинство людей заподозрят неладное, даже если они этот проект до этого в глаза не видели и даже не подозревали что есть такая вещь как верификация email.
Да как-то не заметил особо добавившейся работы от того что я пишу на Scala и Rust, наоборот, тот факт что весь код гарантированно работает исходя из типов, а тесты нужно писать только на критически важную логику здорово уменьшает количество работы по сравнению с динамическими языками где нужно писать 4-5 строк юнит тестов на одну строку кода только для того чтобы быть уверенным что код валиден (не говоря уже о логике)
Так а хентай и прочее разве у нас вообще локализуется/продается? Я что-то особо не интересовался (в Steam, да, полно, но я так понял законопроект о наших магазинах)
Ой, какая неожиданность - все они написаны на С/С++ (в большей степени на С). А как же так то...не надежно все это - сколько безногих разработчиков и промышленных систем.
RFC стабилизирующее no_std в Rust датируется 2015-м годом. Давайте посмотрим когда же были выпущены в продакшн вышеперечисленные RTOS:
Deos is a time and space partitioned real-time operating system (RTOS) that was first certified to DO-178B level A in 1998
Хм, 17 лет...
embOS — The preferred RTOS for embedded systems since 1992
23 года...
FreeRTOS: Initial release:2003
О, всего 12 лет!
И т.д. и т.п. Прям странно что все это RTOS, вышедшие за десятилетия до того как Rust выпустил 1.0 версию (и стабилизировал no_std/no_core функционал) были написаны на C/++ а не Rust. Наверное вы правы, это вина Rust что разработчики решили писать эти системы на C, а не на языке который не будет создан несколько десятилетий спустя...
Так а им-то какой смысл добровольно уходить? Я сильно сомневаюсь что их инвесторам понравится отмазка "по моральным соображениям" когда они увидят прибыль сильно ниже предполагаемой в конце квартала.
Я имел в виду что если дать возможность пользователям выбирать - почти все поставят "как было", потому что главное чтобы у тебя в квартире все было супер, а какие помехи это создаст соседям - "не моя проблема".
А тем у кого дом? Им вместо одного роутера и AP покрывающих весь дом и участок, что, нужно брать роутер, 4-6 AP, да еще и свитч с PoE в придачу? Или делать роутеры отдельно под квартиры и дома? Или тоггл в настройках роутера, который 90% населения будет переключать на более мощный, потому что захотят повесить роутер в прихожей а не по центру квартиры, и будут недовольны что на балконе у них уровень сигнала только 80% а не 99%.
Судя потому что их никто не заставлял уходить, а они сделали это сами, по собственному желанию, впереди паровоза, и сжигая все мосты позади себя - я бы не рассчитывал на их возвращение
Так он уже произошел: Google заблокировала установку и обновление купленных приложений в Android. Не покупку новых или приложения требующие подписку, что можно было бы обосновать, а доступ к тем приложения которые пользователи давно приобрели. И результат этого "подрыва" - тишина.
Все с интерфейсом прекрасно, если BRN использовать полноэкранно а не в окне 800x600, как будто вернулись в 90-е
И правдо сработало. Жаль только радовался я рано - сервер перегружен, в консоли полно 429 ошибок от их sentry, и на любой запрос бот отваливается по таймауту...
С паролем может быть еще хуже, из личного опыта. В проекте которым сейчас занимаюсь случайно получилось так что при восстановлении пароля в базу писался чистый пароль а не его хэш (что, соответственно, означало что A) пользователь не смог-бы войти сменив пароль, и B) было потенциальной уязвимостью), к счастью наш доблестный QA это увидел до выкатки. Как это получилось? Как оказалось, когда все три (инпут с фронта, хэш этого инпута, и хэшированный пароль из базы) все имеют сигнатуру `smthPassword: String` - весьма несложно случайно запихнуть не то значение не в то поле по невнимательности. Решилась проблема использованием тонкой newtype обертки HashedPassword(String), благодаря которой теперь нельзя запихнуть "сырой" пароль String в поле (или функцию) тип которого HashedString, нельзя по-незнанию/наивности сравнить хэш и сырой пароль напрямую, нельзя случайно вывести пароль (точнее его хэш) из микро-сервиса через RPC или записать его в лог, ибо ждя этого типа соответствующие фичи не имплементированы за ненадобностью, etc.
В том что касается первого примера с email - нужно, конечно, подходить к этому без фанатизма, но тем не менее между
и
второй вариант выглядит куда более надежным, так как когда ты не можешь использовать email напрямую (при условии, конечно, что в языке есть средства позволяющие это сделать, как например enum в Rust или closed/sealed типы в Haskell/Scala) и должен руками написать что ты хочешь отправить секретную инфу на конкретно непроверенный email - явно большинство людей заподозрят неладное, даже если они этот проект до этого в глаза не видели и даже не подозревали что есть такая вещь как верификация email.
Да как-то не заметил особо добавившейся работы от того что я пишу на Scala и Rust, наоборот, тот факт что весь код гарантированно работает исходя из типов, а тесты нужно писать только на критически важную логику здорово уменьшает количество работы по сравнению с динамическими языками где нужно писать 4-5 строк юнит тестов на одну строку кода только для того чтобы быть уверенным что код валиден (не говоря уже о логике)
Так а хентай и прочее разве у нас вообще локализуется/продается? Я что-то особо не интересовался (в Steam, да, полно, но я так понял законопроект о наших магазинах)
Игре как бы 37 лет... Не поздновато ее запрещать к продаже? Ее еще нужно постараться найти где купить...
RFC стабилизирующее no_std в Rust датируется 2015-м годом. Давайте посмотрим когда же были выпущены в продакшн вышеперечисленные RTOS:
Хм, 17 лет...
23 года...
О, всего 12 лет!
И т.д. и т.п. Прям странно что все это RTOS, вышедшие за десятилетия до того как Rust выпустил 1.0 версию (и стабилизировал no_std/no_core функционал) были написаны на C/++ а не Rust. Наверное вы правы, это вина Rust что разработчики решили писать эти системы на C, а не на языке который не будет создан несколько десятилетий спустя...
Так а им-то какой смысл добровольно уходить? Я сильно сомневаюсь что их инвесторам понравится отмазка "по моральным соображениям" когда они увидят прибыль сильно ниже предполагаемой в конце квартала.
Я имел в виду что если дать возможность пользователям выбирать - почти все поставят "как было", потому что главное чтобы у тебя в квартире все было супер, а какие помехи это создаст соседям - "не моя проблема".
А тем у кого дом? Им вместо одного роутера и AP покрывающих весь дом и участок, что, нужно брать роутер, 4-6 AP, да еще и свитч с PoE в придачу? Или делать роутеры отдельно под квартиры и дома? Или тоггл в настройках роутера, который 90% населения будет переключать на более мощный, потому что захотят повесить роутер в прихожей а не по центру квартиры, и будут недовольны что на балконе у них уровень сигнала только 80% а не 99%.
Судя потому что их никто не заставлял уходить, а они сделали это сами, по собственному желанию, впереди паровоза, и сжигая все мосты позади себя - я бы не рассчитывал на их возвращение
Нашел даже статью об этом: https://www.bleepingcomputer.com/news/google/google-play-now-blocks-paid-app-downloads-updates-in-russia/
А у вас что за приложения? Наши?
У меня, например, не обновляются/устанавливаются:
https://play.google.com/store/apps/details?id=com.onetwoapps.mh
https://play.google.com/store/apps/details?id=com.teslacoilsw.launcher.prime
https://play.google.com/store/apps/details?id=com.maxmpz.audioplayer.unlock
https://play.google.com/store/apps/details?id=com.TailoredMusic.RainyMood
https://play.google.com/store/apps/details?id=ru.kaomoji.kaomojiapp
Плюс поспрашивал у коллег - куча игр (платных, не f2p) перестала устанавливаться.
Так он уже произошел: Google заблокировала установку и обновление купленных приложений в Android. Не покупку новых или приложения требующие подписку, что можно было бы обосновать, а доступ к тем приложения которые пользователи давно приобрели. И результат этого "подрыва" - тишина.