Т. е. угнать аккаунт вообще зная только номер телефона
Нет, нужно иметь доступ к другой сессии или устройству, чтобы получить код верификации.
А адрес почты указать прямо перед сбросом пароля
Нельзя так сделать. Если почта не указана появится сообщение, что можно только сделать reset аккаунта. Это совсем не то же самое, что "указать почту прямо перед сбросом пароля". Если бы так можно было, это было бы просто смехотворно. 2FA пароль в телеге - это весьма надёжное средство против угона аккаунта, только почту не надо указывать.
Ну может быть из внутренней репы перекидывает во внешнюю один человек?
TDesktop пилится более прозрачно чем другие клиенты, не утверждаю, но может у них и нет внутренней репы для него. Там коммиты выглядят как просто коммиты, а не ~копипаста~ синхронизация из внутренней репы.
Откуда инфа?
Общался когда-то с людьми, близкими к процессам разработки там. У них в команде приветствуется внутренняя конкуренция и ответственность не размазывается на кучу людей. Поэтому, например, у них есть кроссплатформенный TDesktop и отдельный клиент под MacOS на Swift, которые разрабатывают разные люди. И оба официальные.
В общем не стоит сравнивать эти проекты, совершенно разный уровень во всем.
В какой-то степени я согласен. Просто привел пример сложного большого продукта, который пилится довольно скромной по размеру командой разработки.
Плюс, из недавних слухов - в телеграме порядка 50 разработчиков, а обсидиан, насколько я слышал, пилят 2 или 3 человека.
Если вы посмотрите исходники Telegram Desktop, будет видно, что подавляющая часть коммитов там сделана одним человеком. Активно пилят клиенты под каждую платформу те же 2-3 человека.
А как вы сравнивали сложность приложений?
Просто из опыта. Современные мессенджеры - это как раз таки сложные приложения. Особенно Telegram со своими велосипедами, криптографическим протоколом, сериализацией и всей "спорной" функциональностью, которую они туда впихнули за последнее время. Посмотрите исходники android приложения или tdesktop.
И им как-то удаётся всю эту сложность контролировать и поддерживать высокую скорость разработки без особого снижения производительности приложений и появления критических багов (хотя багов там у них хватает, конечно).
Приложение Obsidian тормозит на Android. На десктопе редактор тупит на больших документах.
Если начать еще и гуй писать, то это в разы усложнит разработку
Для Desktop можно было взять Qt, для мобильных платформ Kotlin и Swift. И ничего тормозить не будет если написать нормально. Небольшая команда Telegram как-то справилась же, и приложение у них посложнее будет чем "редактор заметок". Сравните производительность и отзывчивость нативных клиентов телеграма на любой платформе и какой-нибудь Discord.
Я много чего за свою жизнь понаписал. На Электроне, правда, ничего не писал, чему очень рад.
Софт весьма сложный
Что именно там сложного? Редактор сложный для markdown? Который глючит. Или система плагинов и расширения функциональности сложная? Или система построения "графа знаний" по кросс-ссылкам между заметками сложная?
Но, допустим, там есть что-то реально сложное. Это разве оправдание, чтобы делать приложение на Электроне? Или оправдание, что оно должно тормозить? Или сложное приложение нельзя написать "тяп-ляп и в продашкен"?
Так они все на Электроне, хоть Obsidian, хоть Logseq, хоть Joplin...
Нативные приложения давно никто не делает, долго дорого, сложно. А тут тяп-ляп наколбасил и в продакшен. Тормозит и безмерно жрёт ресурсы? Купи компьютер помощнее, нищеброд, у нас супер-современные web-технологии под капотом. Ну и что, что приложение для заметок хочет 50% CPU, 2 гигабайта ОЗУ и при этом тормозит.
В Joplin все данные хранятся в SQLite, при этом до недавнего времени даже не было прямой возможности указать директорию, в которой будет храниться эта БД. Удивительно, конечно.
А ещё Joplin тормозит. Не знаю, что надо такого сделать, чтобы простое приложение для текстовых заметок тормозило, но оно тормозит и на десктопе, и на мобильных платформах. Не иначе как "современные web-технологии" всему виной.
Обычно было как на этой картинке, поэтому через месяц перестал этим пользоваться. Ещё пробовал Codeium в виде плагина для Idea, невозможно пользоваться из-за того, что весь тот бред, что он генерирует, вставляется по кнопке tab. Особенно выбешивает, когда пишешь на Python. Хочешь вставить отступ, а вставляется экран какого-то мусора.
А потом всё тормозит, и персональные данные всё равно утекают. :)
Зачем так всё усложнять?
Управление аккаунтами это обычный сервис по работе с персональными данными. Все, кроме пароля, хранит у себя. Доступы зарезаны максимально, но есть.
Какая разница где хранить пароль, в одной базе или в другой если этот пароль всё равно хранится в виде стойкого к перебору хеша, например Argon2 с десятком раундов? Типа персональные данные можно потерять, а хеши паролей надо хранить под тремя замками? И ради этого городить несколько бэкендов, 3 базы и т.д. Ну смешно же.
База - это просто ещё один кусок вашей системы, не важно как вы её назовёте, у неё есть точно такой же интерфейс для взаимодействия и есть логика хранения данных на уровне хранения данных. Сервис - это просто сущность, которая оперирует данными на входе и на выходе. Нет данных, нет системы, нет ничего.
А можно подумать зарание, и тогда вероятность появления проблем снизится.
Если бы это работало, все бы думали заранее и программы, написанные однажды, никогда не переписывали, и все были бы довольны. Но это не работает. Современные программы и проекты никогда не заканчиваются. Вы можете год проектировать архитектуру, а можете год колбасить "говнокод" на коленке. Всё равно кто-то будет всё это дописывать, переписывать, переделывать, перепроектировать и не один раз, если этот код будет хоть кому-то нужен. Я не видел ни одного проекта, который бы постоянно не пилили, и те, которые были спроектированы заранее, и те, которые писались на коленке "просто, чтобы показать MVP". Выкатываются новые требования и всё начинается снова. Перепиливается архитектура, вставляются костыли, убираются костыли и так до бесконечности.
И смотря на всё это 10 лет я подумал: да нафиг надо, делай проще, как можно проще, всё равно всё выкинут и перепишут заново, как бы ты ни пыжился. Ну вот и делай так, чтобы это было хотя бы проще переписать или не жалко выкинуть, когда появятся очередные требования, повёрнутые на 180 градусов от первоначальной идеи. Я не говорю, что надо писать говнокод и вообще не заниматься проектированием системы, но пытаться всё сделать идеально и правильно заранее никогда не выйдет. Поэтому даже и пытаться не стоит.
На счёт того, что 1 сервис - это всегда проще чем два, то я бы сказал, что почти всегда, но бывает, что проще/удобнее/необходимо сделать два. Всегда есть исключения, всегда есть нюансы.
Она плохая на первый взгляд, на второй она ужасная, а на третий и далее чаще всего просто катастрофа. Это не опрометчиво, это вообще-то требование к микросервисной архитектуре, это ключевой ее паттерн. Если у вас база на несколько сервисов, то это что угодно, но не микро-сервисы. Это не я выдумал, это вытекает из назначения и требований к микросервисам, каждый микросервис должен иметь свою доменную модель, иметь независимый цикл разработки и деплоймента. Это азы микросервисной архитектуры как таковой, в ней расшареная база это анти-паттерн.
А вы никогда не рассматривали базу данных как сервис, который хранит данные? Уберите это неоднозначное слово "микро", потому что вообще не понятно, что такое "микро" сервис и чем он отличается от "нано" сервиса или "мини" сервиса.
База - это просто ещё один сервис, с которым взаимодействуют другие сервисы, у каждого сервиса своя ответственность, каждый может как-то масштабироваться. И не надо никаких догм и карго-культов и рассуждений про "азы микросервисной архитектуры".
Если удобнее сделать, чтобы один кусок вашей распределённой системы писал в базу, а другой читал, ну нет в этом никакой проблемы пока у вас нет никаких проблем. Если появляются проблемы, надо думать дальше.
Не помню уже, что я хотел сказать. С пустым списком работать не будет, конечно. На пустом списке индекс -1 вызовет ошибку IndexError так же как -5 на списке из 3 элементов.
что это написанный с нуля движок это просто обманывать себя и других
И в чём же обман? Они честно пишут в readme, что "The Browser UI has a cross-platform GUI in Qt6 and a macOS-specific GUI in AppKit".
Зачем ему ... три питона (3.8, 3.9 и 3.11)
Не понятно, потому что питоны 3.8, 3.9, 3.11 обратно совместимы за вычетом удалённых deprecated модулей (что-то там удаляли из stdlib в 3.11 или в 3.12, не помню уже). Скорее всего кто-то ленивый сделал кривой пакет в FreeBSD, у которого в зависимостях аж 3 версии Python.
s = 'aaa;bbb;ccc;ddd'
parts = s.split(';')
last = parts[len(parts)-1] # 1
*_, last = s.split(';') # 2
last = s.split(';')[-1] # 3
Опыт показывает, что #3 очевиден, прост и удобен любому разработчику на Python. Особенно в сравнении с #1 где надо написать две строки вместо одной, а ещё посчитать длину списка. Кстати, благодаря отрицательным индексам, первый вариант будет работать с пустым списком без ошибок.
Заворачивание индексов - это просто инструмент, который надо применять там где нужно, а там где не нужно, применять не нужно. Вот и всё. Это так же как с goto, не надо слушать "фанатиков чистоты кода", а использовать, руководствуясь опытом и здравым смыслом.
Если что, я вам минус поставил только в комментарий. Убрать его нельзя, но можно поставить вам плюс в карму ;)
В индустрии не хватает высококвалифицированных людей и профессионалов как бы странно это ни звучало (при том, что мы имеем сейчас карго-культ с идиотскими бесконечными многоступенчатыми алгоритмическими собеседованиями и прочим идиотизмом), и сумасшествие с безумными и бездумными процессами (как описывается в соседней статье) тоже не помогает. Так что люди, которые реализуют какой-нибудь workflow для оплаты, бронирования и т. п. в интернете, не слышали, например, про Temporal, long-running transactions и т. п. И всё это весьма грустно, потому что градус безумия в индустрии повышается, а качество продуктов снижается, при этом вся индустрия переориентируется на выкачивание денег из всех до кого можно дотянуться и в b2c, и в b2b.
В общем, довольно кривой механизм с точки зрения UX. При "добавлении ключа" на винде активируется сначала расширение Bitwarden. Если его закрыть, открывается другой диалог где есть два пункта на выбор: "Windows Hello или внешний электронный ключ" и "Использовать телефон, планшет...". Если выбрать первый пункт, то винда предлагает добавить отпечаток пальца. Если закрыть этот диалог, активируется уже какой-то механизм браузера, который предлагает использовать подключенный аппаратный ключ, но сначала надо создать PIN-код. Это всё выглядит просто как набор костылей каких-то, особенно когда переход к другому способу активируется через закрытие предыдущего диалога. Но я так понимаю, это реализация WebAuthn так криво сделана by design.
Я помню как добавлял ключи для Bitwarden, просто жмешь кнопку "добавить ключ", прикладываешь палец к ключу и готово - ключ добавлен и так несколько раз, чтобы добавить несколько ключей. И все эти ключи будут работать на любом устройстве с которого заходишь в аккаунт.
Они это назвали "Вход по лицу или отпечатку на устройстве". У меня активируется расширение Bitwarden если эту штуку включить и предлагает создать passkey для сохранённого в нём аккаунта. Работает точно так же как с Google-аккаунтами. А вот как добавить несколько YubiKey ключей, которые будут работать с любым устройством, например, не понятно.
Нет, нужно иметь доступ к другой сессии или устройству, чтобы получить код верификации.
Нельзя так сделать. Если почта не указана появится сообщение, что можно только сделать reset аккаунта. Это совсем не то же самое, что "указать почту прямо перед сбросом пароля". Если бы так можно было, это было бы просто смехотворно. 2FA пароль в телеге - это весьма надёжное средство против угона аккаунта, только почту не надо указывать.
TDesktop пилится более прозрачно чем другие клиенты, не утверждаю, но может у них и нет внутренней репы для него. Там коммиты выглядят как просто коммиты, а не ~копипаста~ синхронизация из внутренней репы.
Общался когда-то с людьми, близкими к процессам разработки там. У них в команде приветствуется внутренняя конкуренция и ответственность не размазывается на кучу людей. Поэтому, например, у них есть кроссплатформенный TDesktop и отдельный клиент под MacOS на Swift, которые разрабатывают разные люди. И оба официальные.
В какой-то степени я согласен. Просто привел пример сложного большого продукта, который пилится довольно скромной по размеру командой разработки.
Если вы посмотрите исходники Telegram Desktop, будет видно, что подавляющая часть коммитов там сделана одним человеком. Активно пилят клиенты под каждую платформу те же 2-3 человека.
Просто из опыта. Современные мессенджеры - это как раз таки сложные приложения. Особенно Telegram со своими велосипедами, криптографическим протоколом, сериализацией и всей "спорной" функциональностью, которую они туда впихнули за последнее время. Посмотрите исходники android приложения или tdesktop.
Telegram Android:
Telegram Desktop:
logseq:
И им как-то удаётся всю эту сложность контролировать и поддерживать высокую скорость разработки без особого снижения производительности приложений и появления критических багов (хотя багов там у них хватает, конечно).
В том же logseq вот issues про performance.
https://github.com/logseq/logseq/issues?q=is%3Aissue+is%3Aopen+slow+label%3A%3Atype%2Fperformance
Приложение Obsidian тормозит на Android. На десктопе редактор тупит на больших документах.
Для Desktop можно было взять Qt, для мобильных платформ Kotlin и Swift. И ничего тормозить не будет если написать нормально. Небольшая команда Telegram как-то справилась же, и приложение у них посложнее будет чем "редактор заметок". Сравните производительность и отзывчивость нативных клиентов телеграма на любой платформе и какой-нибудь Discord.
Я много чего за свою жизнь понаписал. На Электроне, правда, ничего не писал, чему очень рад.
Что именно там сложного? Редактор сложный для markdown? Который глючит. Или система плагинов и расширения функциональности сложная? Или система построения "графа знаний" по кросс-ссылкам между заметками сложная?
Но, допустим, там есть что-то реально сложное. Это разве оправдание, чтобы делать приложение на Электроне? Или оправдание, что оно должно тормозить? Или сложное приложение нельзя написать "тяп-ляп и в продашкен"?
Так они все на Электроне, хоть Obsidian, хоть Logseq, хоть Joplin...
Нативные приложения давно никто не делает, долго дорого, сложно. А тут тяп-ляп наколбасил и в продакшен. Тормозит и безмерно жрёт ресурсы? Купи компьютер помощнее, нищеброд, у нас супер-современные web-технологии под капотом. Ну и что, что приложение для заметок хочет 50% CPU, 2 гигабайта ОЗУ и при этом тормозит.
Они блокируют доступ к своему сайту с IP адресов из РФ. Понятно, что это open source и репа доступна на гитхабе, но осадочек остаётся.
В Joplin все данные хранятся в SQLite, при этом до недавнего времени даже не было прямой возможности указать директорию, в которой будет храниться эта БД. Удивительно, конечно.
А ещё Joplin тормозит. Не знаю, что надо такого сделать, чтобы простое приложение для текстовых заметок тормозило, но оно тормозит и на десктопе, и на мобильных платформах. Не иначе как "современные web-технологии" всему виной.
Обычно было как на этой картинке, поэтому через месяц перестал этим пользоваться. Ещё пробовал Codeium в виде плагина для Idea, невозможно пользоваться из-за того, что весь тот бред, что он генерирует, вставляется по кнопке tab. Особенно выбешивает, когда пишешь на Python. Хочешь вставить отступ, а вставляется экран какого-то мусора.
Просто структуру словаря надо делать упорядоченной по добавлению ключей. Как минимум иметь отдельную реализацию key-ordered контейнера. Столько проблем во многих случаях сразу уходит.
https://pypy.org/posts/2015/01/faster-more-memory-efficient-and-more-4096950404745375390.html
А потом всё тормозит, и персональные данные всё равно утекают. :)
Зачем так всё усложнять?
Какая разница где хранить пароль, в одной базе или в другой если этот пароль всё равно хранится в виде стойкого к перебору хеша, например Argon2 с десятком раундов? Типа персональные данные можно потерять, а хеши паролей надо хранить под тремя замками? И ради этого городить несколько бэкендов, 3 базы и т.д. Ну смешно же.
База - это просто ещё один кусок вашей системы, не важно как вы её назовёте, у неё есть точно такой же интерфейс для взаимодействия и есть логика хранения данных на уровне хранения данных. Сервис - это просто сущность, которая оперирует данными на входе и на выходе. Нет данных, нет системы, нет ничего.
Если бы это работало, все бы думали заранее и программы, написанные однажды, никогда не переписывали, и все были бы довольны. Но это не работает. Современные программы и проекты никогда не заканчиваются. Вы можете год проектировать архитектуру, а можете год колбасить "говнокод" на коленке. Всё равно кто-то будет всё это дописывать, переписывать, переделывать, перепроектировать и не один раз, если этот код будет хоть кому-то нужен. Я не видел ни одного проекта, который бы постоянно не пилили, и те, которые были спроектированы заранее, и те, которые писались на коленке "просто, чтобы показать MVP". Выкатываются новые требования и всё начинается снова. Перепиливается архитектура, вставляются костыли, убираются костыли и так до бесконечности.
И смотря на всё это 10 лет я подумал: да нафиг надо, делай проще, как можно проще, всё равно всё выкинут и перепишут заново, как бы ты ни пыжился. Ну вот и делай так, чтобы это было хотя бы проще переписать или не жалко выкинуть, когда появятся очередные требования, повёрнутые на 180 градусов от первоначальной идеи. Я не говорю, что надо писать говнокод и вообще не заниматься проектированием системы, но пытаться всё сделать идеально и правильно заранее никогда не выйдет. Поэтому даже и пытаться не стоит.
На счёт того, что 1 сервис - это всегда проще чем два, то я бы сказал, что почти всегда, но бывает, что проще/удобнее/необходимо сделать два. Всегда есть исключения, всегда есть нюансы.
А вы никогда не рассматривали базу данных как сервис, который хранит данные? Уберите это неоднозначное слово "микро", потому что вообще не понятно, что такое "микро" сервис и чем он отличается от "нано" сервиса или "мини" сервиса.
База - это просто ещё один сервис, с которым взаимодействуют другие сервисы, у каждого сервиса своя ответственность, каждый может как-то масштабироваться. И не надо никаких догм и карго-культов и рассуждений про "азы микросервисной архитектуры".
Если удобнее сделать, чтобы один кусок вашей распределённой системы писал в базу, а другой читал, ну нет в этом никакой проблемы пока у вас нет никаких проблем. Если появляются проблемы, надо думать дальше.
Не помню уже, что я хотел сказать. С пустым списком работать не будет, конечно. На пустом списке индекс -1 вызовет ошибку IndexError так же как -5 на списке из 3 элементов.
И в чём же обман? Они честно пишут в readme, что "The Browser UI has a cross-platform GUI in Qt6 and a macOS-specific GUI in AppKit".
Не понятно, потому что питоны 3.8, 3.9, 3.11 обратно совместимы за вычетом удалённых deprecated модулей (что-то там удаляли из stdlib в 3.11 или в 3.12, не помню уже). Скорее всего кто-то ленивый сделал кривой пакет в FreeBSD, у которого в зависимостях аж 3 версии Python.
Посмотрите на bruno
Какой код читается лучше
#1,#2или#3?Опыт показывает, что
#3очевиден, прост и удобен любому разработчику на Python. Особенно в сравнении с#1где надо написать две строки вместо одной, а ещё посчитать длину списка. Кстати, благодаря отрицательным индексам, первый вариант будет работать с пустым списком без ошибок.Заворачивание индексов - это просто инструмент, который надо применять там где нужно, а там где не нужно, применять не нужно. Вот и всё. Это так же как с goto, не надо слушать "фанатиков чистоты кода", а использовать, руководствуясь опытом и здравым смыслом.
Если что, я вам минус поставил только в комментарий. Убрать его нельзя, но можно поставить вам плюс в карму ;)
В индустрии не хватает высококвалифицированных людей и профессионалов как бы странно это ни звучало (при том, что мы имеем сейчас карго-культ с идиотскими бесконечными многоступенчатыми алгоритмическими собеседованиями и прочим идиотизмом), и сумасшествие с безумными и бездумными процессами (как описывается в соседней статье) тоже не помогает. Так что люди, которые реализуют какой-нибудь workflow для оплаты, бронирования и т. п. в интернете, не слышали, например, про Temporal, long-running transactions и т. п. И всё это весьма грустно, потому что градус безумия в индустрии повышается, а качество продуктов снижается, при этом вся индустрия переориентируется на выкачивание денег из всех до кого можно дотянуться и в b2c, и в b2b.
В общем, довольно кривой механизм с точки зрения UX. При "добавлении ключа" на винде активируется сначала расширение Bitwarden. Если его закрыть, открывается другой диалог где есть два пункта на выбор: "Windows Hello или внешний электронный ключ" и "Использовать телефон, планшет...". Если выбрать первый пункт, то винда предлагает добавить отпечаток пальца. Если закрыть этот диалог, активируется уже какой-то механизм браузера, который предлагает использовать подключенный аппаратный ключ, но сначала надо создать PIN-код. Это всё выглядит просто как набор костылей каких-то, особенно когда переход к другому способу активируется через закрытие предыдущего диалога. Но я так понимаю, это реализация WebAuthn так криво сделана by design.
Я помню как добавлял ключи для Bitwarden, просто жмешь кнопку "добавить ключ", прикладываешь палец к ключу и готово - ключ добавлен и так несколько раз, чтобы добавить несколько ключей. И все эти ключи будут работать на любом устройстве с которого заходишь в аккаунт.
Они это назвали "Вход по лицу или отпечатку на устройстве". У меня активируется расширение Bitwarden если эту штуку включить и предлагает создать passkey для сохранённого в нём аккаунта. Работает точно так же как с Google-аккаунтами. А вот как добавить несколько YubiKey ключей, которые будут работать с любым устройством, например, не понятно.