Сейчас изучаю как сделать SSO, т.к. уже понял, насколько регистрация и логин без этого неудобные)
Я бы советовал делать отдельно LDAP и уже поверх него SSO через федерацию. 389ds (или его же в составе freeipa) + keycloak, например. Рано или поздно можно наткнуться на что-нибудь нужное экзотическое, которое умеет LDAP, но не умеет SAML/OIDC и LDAP может пригодиться (хотя все фичи keycloak, типа 2fa, конечно, работать в LDAP аутентификации не будут). И обязательно ещё заранее проверить, что выбранный LDAP сервер умеет разворачивать вложенность групп (openldap, например, не умеет), потому что на этом, обычно, строится вся система прав, в т.ч. то, что keycloak отдаёт в groups клиенту.
А насчёт tailscale у меня сомнения. Он же в базе через свой проприетарный софт идёт.
Да, я именно про headscale, от tailscale будут нужны только клиенты. Tailscale, насколько я знаю, вообще поблочил ру-сегмент в своём облаке, да и даже без этой шизы, идея облачного координационного сервера для своей VPN сети звучит экстремальненько. Headscale умеет OIDC как раз (в т.ч. авторизацию через членство в группе): https://headscale.net/development/ref/oidc/
SSO я сознательно не внедрял ПОКА ЧТО. Synapse поддерживает OpenID Connect, и можно было бы развернуть Authentik или Keycloak для единой точки авторизации. Но для 15 человек это ту мач
Потом это будет сделать ощутимо сложнее, если успеют добавиться другие сервисы, далеко не любой сервис нормально переживает переезд с внутренней БД аутентификации на SSO с примапливанием пользователей. Да и даже в вашей случае, SSO, например, даст возможность использовать tailscale вместо чистого wg под той же учёткой, под которой пользователь заходит в matrix.
Павел занимался продуктовой частью. Он сделал ставку на облачную синхронизацию: где вся история сообщений хранится в облаке и доступна с любого устройства. Меняешь телефон или переходишь на десктоп, логинишься, и все переписки на месте.
В 2013 году такого не было ни у одного мессенджера.
Разве джаббер в исполнении гугла не умел этого с самого начала?
Обычные чаты работают через серверы Telegram: сообщения шифруются при передаче, но на сервере компания технически имеет к ним доступ.
Не очень понятно, ведь ровно по этой же причине Павлу Дурову ранее не подошли все существующие варианты (“когда за его дверью стояли силовики, он не знал, каким способом связаться с братом”). Или суть в том, что там компании имели полный доступ, а тут телеграмм имеет доступ только “технически”?
Но секретные чаты нужно включать вручную для каждой беседы, и работают они только на одном устройстве без синхронизации.
Вот xmpp решил эту проблему году в 2018 кажется (точнее решил её, кажется, signal, а xmpp адаптировал) и e2e там работает с любым количеством устройств пользователя в чате. А Телеграмм всё никак не может? Или это просто не то, что Telegram, как и любой нормальной коммерческой компании, интересно?
К 2025 году Дуров заявил о масштабной модерации: ежемесячно блокируется около миллиона каналов и 10 млн аккаунтов за нарушения. Telegram запустил публичную страницу прозрачности модерации.
И всё равно огромное множество крупных чатов нон-стопом спамятся наркоботами, уровня “Подвезти материалы к подъезду - 5000 р за час”. Но попробуй только запустить какой-нибудь WTelegramClient, чтобы поиграться, и отлетишь в бан моментально.
Telegram - отличный, выдающийся и очень удобный продукт, Павел Дуров талантливый, если не гениальный, продажник и руководитель. Но это именно коммерческий продукт. Всю возвышенную лапшу про борьбу за приватность пользователей нужно делить на десять и заранее понимать, что все ваши открытые и групповые чаты, да и просто сетевая телеметрия, вовсю насилуются Telegram, как минимум, в части биг даты анализа, а может и не только в его рамках, а может и не только Telegram их насилует. И далеко не весь этот анализ идёт в ваших интересах, как пользователя.
Вы только что сократили raw-данные в надежде на то, что "серия 306 невозможна". А что если станет возможна, что будете делать с человеком со старым паспортом?
Вероятность того, что серия 306 станет возможной и будет отличаться от серии 0306 гораздо ниже вероятности того, что, например, серия станет пятизначной с добавлением числового суффикса из-за превышения количества выдаваемых паспортов в промежуток времени в московском регионе. Это очевидно просто из сути разрядов серии (код окато + код бланка). При этом, решение автора ломается на 5 значности, а bigint нет.
Зачем изощряться и стрелять себе в ногу, если можно не стрелять?
Потому что тут нет никакого выстрела в ногу, это вполне приемлемое решение.
Но зачем изначально создавать себе проблему на уровне хранения (терять данные)
В хранении bigint-ом нет никакой потери данных. Нет коллизий, из хранимого значения однозначно восстанавливается отображаемое значение и обратно. Так можно вообще заявить, что хранение дат timestamp-ом - это потеря данных.
чтобы потом героически её решать через View?
Хранение bigint-ом не требует никакого ощутимого оверхеда в части разработки и развития. Ну и суть подобного решения очевидна - это повышение производительности. Меня изначально смутило заявление, что по производительности индексов bigint и char(10) " разница практически нулевая ". Мой опыт, да и просто банальная логика говорит об обратном. Загрузить два значения в два регистра и сделать cmp гораздо быстрее, чем побайтово грузить строки и cmp их.
Меня это заинтересовало и я набросал простейший тест - инсёртим N номеров, ребилдим индекс, проверяем M номеров (90% существующих, 10% несуществующих). У меня получилось, что CHAR(10) минимум в полтора раза медленнее BIGINT и чем больше N, тем больше разница, конечно же.
Естественно, далеко не всегда нужно гнаться за этой производительностью, но с учётом того, что это практически ничего не стоит в части оверхеда, то BIGINT вполне себе жизнеспособный вариант, наряду с CHAR(10). А CHAR(10), например, будет быстрее в извлечении кусков серии, чем BIGINT.
если МВД добавит пятую цифру, букву или дефис, тип CHAR или VARCHAR мигрировать/расширить гораздо проще
То ваша схема просто ляжет с ошибкой транкейта и потребуется доработка физического хранилища.
А вот если вы заложились на INTEGER, то при появлении букв ваша схема просто ляжет с ошибкой типизации.
То есть потребуется доработка физического хранилища.
А вот если МВД добавит пятую цифру в серию (что гораздо вероятнее, чем букву), то в случае BIGINT потребуется только доработка представления, а в случае CHAR(10) - хранилища.
Представьте: завтра к этой базе подключается новый микросервис, BI-система для аналитики или понадобится сырая выгрузка в CSV. Каждому новому клиенту придется заново писать этот костыль с подстановкой нулей.
Нет, не придётся, в базах существуют представления.
Но, вообще говоря, мой комментарий был про то, что такой механизм хранения никак не ломает идентификацию человека.
Да и следуя вашей же аргументации, я могу вам сказать - представьте, что завтра в вашей базе начинают хранить не только российские, но и паспорта других стран. Или представьте, что завтра в вашей базе начинают хранить не только внутренние, но и загранпаспорта. Ваша предлагаемая схема готова к этому?
Паспорт серии 0306 и паспорт серии 306 – это юридически разные документы.
Разве количество цифр в серии не всегда равно 4? Потому что я не очень понимаю, какая проблема в том, чтобы хранить 0306 как 306, если серия 306 невозможна. Никто не мешает отображать 306 как 0306, при этом.
Любой платеж ЖКХ с банковской карты это персональные данные
Данные лица, на которое оформлен договор, у всех этих организаций есть и так, без каких-либо платежей. Данные банковских карт этим организациям не передаются.
Никаких даже местных консультантов. И, упаси боже, никаких русскоязычных.
Есть определённая ирония в том, что и статья автора является консультацией от русскоязычного. То есть автор заложил оригинальную пасхалку - предложил игнорировать свою статью в самой статье.
То есть, грубо говоря, расходы операторов на администрирование этого процесса должны быть заложены в стоимость других услуг оператора, либо в госрасходы (если предполагается дотировать операторам эти расходы). Отличный план, вполне в стиле других государственных решений.
Интересный подход. Так можно пользователей годами динамить с поддержкой любой технологии, в ожидании, пока она помрёт, а потом просто объявить, что оно и не было никогда нужно.
Если доход квалифицируется как доход физлица, итоговая нагрузка возвращается к привычным 13%+1%.
При заявленном доходе 9кк, итоговая нагрузка будет 16%+1%. Какая-то старая нейрохрень это писала что ли, с обучением на данных до 2021?
Но налоговая , налоговая может прийти к выводу, что доход связан с деятельностью российского ИП, и применить к нему УСН.
Однако ключевой вопрос заключается не в размере налога, а в устойчивости конструкции. Если налоговая сочтёт, что доход не связан с деятельностью ИП или что иностранная структура носит формальный характер, возможна переквалификация дохода и применение НДФЛ, что увеличит нагрузку до 13%. Это не неизбежный сценарий, но именно эта неопределённость
Нет тут никакой неопределённости. По аналогии со счётом ФЛ за рубежом, ИП может уведомить о наличии счёта за рубежом, который используется в деятельности ИП. После этого, он будет обязан подавать отчётность по этому счёту каждый квартал, причём разные налоговые могут требовать разных исходников от банка, вплоть до нотариального перевода.
у вас как пользователя не работают банки, это проблема конкретно вас
Ну нет, это проблема ублюдочного подхода компании эппл к навязыванию своей экосистемы. Не просто же так в европе эппл старательно продавливают на эти самые изменения в части деплоя и nfc.
Давайте представим ситуацию. Я однорукий человек и мне на скакалке скакать не нравится, ну неудобно. И вот я жалуюсь на производителей скакалок, что они обо мне не думают.
Аналогия - моё почтение.
Поэтому я предлагаю мыслить объективно.
Никакой объективности ни до, ни в этом комментарии не увидел. Речь о том, что, конкретно вас эппл устраивает и это прекрасно. Но не стоит пытаться делать из этого выводы космического масштаба (и глупости), про сравения открытости ведроида и айос. Вам же даже чтобы набросить говна на вентилятор в сторону ведроида приходится регистрировать мусорный акк, это уже очень забавный маркер.
Для меня техника от apple прекрасно работает из коробки. я не хочу тратить время на вопросы типа "какой там архитектуры у меня apk установится", где его найти, как получить рут (который кстати мне последний раз нужен был чтоб телефон на новую версию андроид установить). На вопросы типа, а как мне скинуть файл с телефона на комп без кабеля, как начать читать статью с телефона, а потом моментально открыть страницу браузера и все вкладки на ноуте.
По описанию проблем выглядит так, что у вас был какой-то ноунейм ведроид за $50. Берите ведроид за те же $1k+, что и айфон и никаких подобных вопросов у вас не возникнет.
Да вроде никакой разницы с описанием автора не будет, кроме дополнительной необходимости в ddns клиенте.
Я бы советовал делать отдельно LDAP и уже поверх него SSO через федерацию. 389ds (или его же в составе freeipa) + keycloak, например. Рано или поздно можно наткнуться на что-нибудь нужное экзотическое, которое умеет LDAP, но не умеет SAML/OIDC и LDAP может пригодиться (хотя все фичи keycloak, типа 2fa, конечно, работать в LDAP аутентификации не будут). И обязательно ещё заранее проверить, что выбранный LDAP сервер умеет разворачивать вложенность групп (openldap, например, не умеет), потому что на этом, обычно, строится вся система прав, в т.ч. то, что keycloak отдаёт в groups клиенту.
Да, я именно про headscale, от tailscale будут нужны только клиенты. Tailscale, насколько я знаю, вообще поблочил ру-сегмент в своём облаке, да и даже без этой шизы, идея облачного координационного сервера для своей VPN сети звучит экстремальненько. Headscale умеет OIDC как раз (в т.ч. авторизацию через членство в группе): https://headscale.net/development/ref/oidc/
В ближайшем headscale 0.29 обещают полную поддержку grants, тоже полезная вещь для управления https://tailscale.com/docs/features/access-control/grants
Потом это будет сделать ощутимо сложнее, если успеют добавиться другие сервисы, далеко не любой сервис нормально переживает переезд с внутренней БД аутентификации на SSO с примапливанием пользователей. Да и даже в вашей случае, SSO, например, даст возможность использовать tailscale вместо чистого wg под той же учёткой, под которой пользователь заходит в matrix.
Разве джаббер в исполнении гугла не умел этого с самого начала?
Не очень понятно, ведь ровно по этой же причине Павлу Дурову ранее не подошли все существующие варианты (“когда за его дверью стояли силовики, он не знал, каким способом связаться с братом”). Или суть в том, что там компании имели полный доступ, а тут телеграмм имеет доступ только “технически”?
Вот xmpp решил эту проблему году в 2018 кажется (точнее решил её, кажется, signal, а xmpp адаптировал) и e2e там работает с любым количеством устройств пользователя в чате. А Телеграмм всё никак не может? Или это просто не то, что Telegram, как и любой нормальной коммерческой компании, интересно?
И всё равно огромное множество крупных чатов нон-стопом спамятся наркоботами, уровня “Подвезти материалы к подъезду - 5000 р за час”. Но попробуй только запустить какой-нибудь WTelegramClient, чтобы поиграться, и отлетишь в бан моментально.
Telegram - отличный, выдающийся и очень удобный продукт, Павел Дуров талантливый, если не гениальный, продажник и руководитель. Но это именно коммерческий продукт. Всю возвышенную лапшу про борьбу за приватность пользователей нужно делить на десять и заранее понимать, что все ваши открытые и групповые чаты, да и просто сетевая телеметрия, вовсю насилуются Telegram, как минимум, в части биг даты анализа, а может и не только в его рамках, а может и не только Telegram их насилует. И далеко не весь этот анализ идёт в ваших интересах, как пользователя.
Заявление, конечно, смелое, но позиция юристов Motorola может быть несколько другой.
Есть, например, бесплатный и довольно удобный https://github.com/Ylianst/MeshCentral - вполне неплохая self-hosted замена.
Вероятность того, что серия 306 станет возможной и будет отличаться от серии 0306 гораздо ниже вероятности того, что, например, серия станет пятизначной с добавлением числового суффикса из-за превышения количества выдаваемых паспортов в промежуток времени в московском регионе. Это очевидно просто из сути разрядов серии (код окато + код бланка). При этом, решение автора ломается на 5 значности, а bigint нет.
Потому что тут нет никакого выстрела в ногу, это вполне приемлемое решение.
Уже давно ответил
В хранении bigint-ом нет никакой потери данных. Нет коллизий, из хранимого значения однозначно восстанавливается отображаемое значение и обратно. Так можно вообще заявить, что хранение дат timestamp-ом - это потеря данных.
Хранение bigint-ом не требует никакого ощутимого оверхеда в части разработки и развития. Ну и суть подобного решения очевидна - это повышение производительности. Меня изначально смутило заявление, что по производительности индексов bigint и char(10) " разница практически нулевая ". Мой опыт, да и просто банальная логика говорит об обратном. Загрузить два значения в два регистра и сделать cmp гораздо быстрее, чем побайтово грузить строки и cmp их.
Меня это заинтересовало и я набросал простейший тест - инсёртим N номеров, ребилдим индекс, проверяем M номеров (90% существующих, 10% несуществующих). У меня получилось, что CHAR(10) минимум в полтора раза медленнее BIGINT и чем больше N, тем больше разница, конечно же.
Естественно, далеко не всегда нужно гнаться за этой производительностью, но с учётом того, что это практически ничего не стоит в части оверхеда, то BIGINT вполне себе жизнеспособный вариант, наряду с CHAR(10). А CHAR(10), например, будет быстрее в извлечении кусков серии, чем BIGINT.
То ваша схема просто ляжет с ошибкой транкейта и потребуется доработка физического хранилища.
То есть потребуется доработка физического хранилища.
А вот если МВД добавит пятую цифру в серию (что гораздо вероятнее, чем букву), то в случае BIGINT потребуется только доработка представления, а в случае CHAR(10) - хранилища.
То и вариант схемы, предложенный автором, перестанет удовлеторять требованиям.
Нет, не придётся, в базах существуют представления.
Но, вообще говоря, мой комментарий был про то, что такой механизм хранения никак не ломает идентификацию человека.
Да и следуя вашей же аргументации, я могу вам сказать - представьте, что завтра в вашей базе начинают хранить не только российские, но и паспорта других стран. Или представьте, что завтра в вашей базе начинают хранить не только внутренние, но и загранпаспорта. Ваша предлагаемая схема готова к этому?
Разве количество цифр в серии не всегда равно 4? Потому что я не очень понимаю, какая проблема в том, чтобы хранить 0306 как 306, если серия 306 невозможна. Никто не мешает отображать 306 как 0306, при этом.
Данные лица, на которое оформлен договор, у всех этих организаций есть и так, без каких-либо платежей. Данные банковских карт этим организациям не передаются.
Есть определённая ирония в том, что и статья автора является консультацией от русскоязычного. То есть автор заложил оригинальную пасхалку - предложил игнорировать свою статью в самой статье.
Так и matrix прекрасно бегает в контейнере на сервере.
То есть, грубо говоря, расходы операторов на администрирование этого процесса должны быть заложены в стоимость других услуг оператора, либо в госрасходы (если предполагается дотировать операторам эти расходы). Отличный план, вполне в стиле других государственных решений.
Зашквар зашкваром, а кушать всем хочется.
Интересный подход. Так можно пользователей годами динамить с поддержкой любой технологии, в ожидании, пока она помрёт, а потом просто объявить, что оно и не было никогда нужно.
gitea -> forgejo
https://forgejo.org/2024-02-forking-forward/
При заявленном доходе 9кк, итоговая нагрузка будет 16%+1%. Какая-то старая нейрохрень это писала что ли, с обучением на данных до 2021?
Нет тут никакой неопределённости. По аналогии со счётом ФЛ за рубежом, ИП может уведомить о наличии счёта за рубежом, который используется в деятельности ИП. После этого, он будет обязан подавать отчётность по этому счёту каждый квартал, причём разные налоговые могут требовать разных исходников от банка, вплоть до нотариального перевода.
Ну нет, это проблема ублюдочного подхода компании эппл к навязыванию своей экосистемы. Не просто же так в европе эппл старательно продавливают на эти самые изменения в части деплоя и nfc.
Аналогия - моё почтение.
Никакой объективности ни до, ни в этом комментарии не увидел. Речь о том, что, конкретно вас эппл устраивает и это прекрасно. Но не стоит пытаться делать из этого выводы космического масштаба (и глупости), про сравения открытости ведроида и айос. Вам же даже чтобы набросить говна на вентилятор в сторону ведроида приходится регистрировать мусорный акк, это уже очень забавный маркер.
По описанию проблем выглядит так, что у вас был какой-то ноунейм ведроид за $50. Берите ведроид за те же $1k+, что и айфон и никаких подобных вопросов у вас не возникнет.