Pavel Sherer
Вариант, да. Посмотрю. Пока вижу только потенциальную проблему с контрастностью - на больших изображениях это норм, на маленьком экране распознавание может страдать
Встречи с партнёрами можно запланировать так, чтобы было с кем оставить ребёнка. А когда вам приходит сообщение, что на следующий день нужно явиться, или откажут в регистрации, тут не до особенного выбора. Это раз.
Дети вовсе не всегда плачут. Это два.
Кормящая мать не должна напрочь выпадать из жизни и на несколько лет становиться терпеливым придатком в ребёнку. Вы правда считаете, что ребёнок на деловой встрече с партнёрами всегда приводит к разрыву деловых отношений? Не повезло вам с партнёрами. Если они физиологические обстоятельства не в состоянии принять, то что будет, когда дело дойдёт до финансовых? Это три.
Не очень понял, при чём тут фраза "или же считаете, что всем вам должны". Лично я считаю, что да, ФНС мне должна. Хотя бы потому, что я исправно плачу налоги и вправе рассчитывать, что мои процедурные вопросы будут решены согласно закону. Это четыре.
Шаг "заполнено корректно" и есть валидация данных на клиенте до отправки формы. И такая же валидация есть на сервере.
Речь шла именно про автологин при переходе на восстановление доступа.
Кроме того, технически нет возможности отследить, из пересланного ли письма перешёл пользователь.
Никак. Если пользователь переслал письмо с восстановлением доступа другому пользователю (или даже просто ссылку), то тут ничего не поделать. Социнженерию никто не отменял.
Это да, конечно. Если не день возиться, можно и руками.
В следующих апдейтах планирую сделать возможность ресайзить и двигать QR-код. Там есть некоторые сложности: в частности, при слишком мелком размере код перестанет читаться. То же самое при "украшательстве" кода - нужно быть осторожным с такими фичами. Но в том или ином виде реализовать планирую, да.
Во-первых, не на всех смартфонах есть такая возможность. Мой самсунг, например, не умеет так делать. Во-вторых, вы можете заполнить не все поля поля контакта, а только те, которые нужно. В-третьих, приложение создаёт готовый фон для экрана блокировки - с сохранением размеров изображения.
Не всех, только старых и, как правило, китайских.
Можно использовать сторонние приложения для считывания
Это проблема, как правило, только китайских смартфонов старых моделей. В остальных ок считывается кириллица.
Да, я знаю, и об этом тоже написал. Весь смысл в том, чтобы не заморачиваться с условным фотошопом.
В vCard можно внести место работы и должность - тогда таких вопросов не возникнет.
Разовый, конечно
Пока нет, но я работаю в этом направлении :)
Спасибо :) Если честно, готовых решений прям не встречал. Все проекты разные, на разных технологиях и с разными проектными подходами. Давно планировал написать такое на ноде и пхп, но вряд ли в ближайшее время дойдут руки.
Спасибо, я стараюсь
Забавный баг, комменты местами поменялись.
Клёвый вопрос, спасибо. Этот кейс выходит за рамки непосредственно регистрации, но решаем довольно просто.
1. Если пользователь авторизован, и он прикрепляет новую соцсеть, то сначала мы проверяем, вернула ли соцсеть email. Если email не возвращён или email соответствует текущему, просто прикрепляем соцсеть к аккаунту.
2. Если соцсеть вернула email, отличающийся от того, под которым зарегистрирован текущий пользователь, то у нас снова проверка: есть ли в базе зарегистрированный аккаунт с этим email. Если нет, то прикрепляем соцсеть к аккаунту. Плюс здесь мы можем вывести новый email как резервный, например — это уже зависит от конкретных механик продукта.
3. Если email, который вернула соцсеть, прикреплён к другому аккаунту, то мы проверяем, прикреплена ли текущая соцсеть к аккаунту-владельцу нового email. Если прикреплена, то отказываем текущему пользователю в прикреплении соцсети, ссылаясь на то, что аккаунт с таким email уже зарегистрирован. Этот шаг необязателен и подходит для сервисов с высоким уровнем предиктивной безопасности (финтех, например).
4. Если текущая соцсеть не прикреплена к аккаунту-владельцу нового email, то предлагаем объединить аккаунты. Для этого отправляем на новый email подтверждающее письмо, и ждём, пока пользователь пройдёт по ссылке/скопирует код и тп. В это время можем дополнительно уведомить аккаунт-владельца нового email: например, отправить в аккаунт уведомление о попытке прикреплении его соцсетки к другому профилю.
5. После подтверждения нового email объединяем аккаунты. Эта механика уже совсем индивидуальная для каждого проекта. Плюс, как и в шаге 2, можем из нового email сделать резервный.
Шаги 3 и 4 можно миксовать, в зависимости от особенностей продукта и целевой аудитории. Понятно, что этот алгоритм подойдёт далеко не всем, но его совершенно точно можно подпилить под себя.
Ну, во-первых, лэптоп, если уж придираться. Во-вторых, сканирование сетей, например. И вообще секьюрити-чекинг мобильный. Арч хорош тем, что там нет ничего лишнего. И на стареньком ноуте, который больше не для чего уже и не годен, арч - прекрасный выбор. А вы что предлагаете? Убунту и прочие дебианы? Мне на нём всякие маркеты, офисы и гномы не нужны. Для этого есть десктоп и основной ноут.
Вообще, у арча вполне себе конкретные задачи. А вы продолжайте писать комментарии о том, в чём не понимаете. Вы же не такой, как все.
Не слушайте никого, статья норм и Арч норм)
Забыл тег <sarcasm>, но это и не Хабр. А вообще, спасибо, крутая статья. Завтра же попробую накатить на ноут.
Ничего не понятно, но ооочень интересно!
Пожалуйста)
Если пользователь пока не подтвердил email (или соцсеть его не вернула), то ему может быть доступна ограниченная функциональность (например, только просмотр). Блокировать или нет основную функциональность — это уже больше вопрос к основной механике продукта, как и объединение аккаунтов с разными email.
Более того, история с объединением аккаунтов вообще общая и не относится напрямую к регистрации (например, соцсеть может вернуть другой email — и тогда для появления "условий задачи" даже не понадобится отложенное подтверждение).
В целом, ваш вопрос справедлив, но ответить "универсально" я на него не могу, всё очень сильно зависит от особенностей конкретного продукта. Если выкинуть из требований, указанных в начале статьи, обязательность подтверждённого email, то достаточно будет просто убрать пару веток из схем.
Отчасти согласен. Например, подрастающее поколение email вообще использует редко. Однако есть и в обратную сторону доводы:
1. Пока что регистрация через номер телефона имеет в среднем меньшую конверсию, чем через email. Для того, чтобы запрашивать номер телефона, сервис должен быть либо напрямую связан с финансами (например, тот же интернет-магазин, которому пользователь уже доверил свои деньги), либо обладать высоким кредитом доверия у пользователей.
2. Стоимость SMS в среднем пара рублей. В зависимости от продукта, один пользователь может за месяц тратить от 1-ой до 6-ти SMS. При невысокой LTV это может здорово шарахнуть по юнит-экономике.
3. Маркетинг почему-то продолжает любить email даже в наши дни.
Однако в целом, вход через SMS часто удобнее, да.
Первая часть вашего ответа спорная в сценарной области. Вторая же просто не обоснована и даже оскорбительна. Думаю, разговор закончен, всего доброго.
А расскажите, пожалуйста, как повышаются риски компрометации аккаунта, если пользователь использует почту, а не логин? Посредством социнженерии? В 99% случаев нет разницы, email или логин вытаскивать из доверчивых пользователей или из их скомпрометированных устройств.
И да, я, как вы выразились, "побежал по популярной дорожке" удобства пользователей. Почти все цифровые продукты — это бизнес. В наше время невозможно сделать продукт успешным, если он неудобен пользователям. А без успешности у него не будет денег. А без денег нечем будет платить разработчикам и прочим членам проектной команды. Как итог: если продукты не будут удобными, то такие "борцы", как вы, останетесь без работы.
И заметьте, я не призываю полностью отказываться от безопасности или даже серьёзно её снижать. Перечитайте статью.
1. Можно, там сохраняется изображение.
2. Нет, увы, нельзя.
3. Тоже нельзя, изображение в base64 будет слишком много весить, QR-код станет нечитаемым.