ym
Над 2fa подключить бы
Size: a a a
2021 January 26
b
Не надо смотреть. Домохозяйки сидят в вк или ок. Или в подобных соцсетях. Речь вообще об МВП. И домохозяйке намного сложнее войти через мыло, чем через соцсеть
b
Не совсем понимаю, зачем вам описывать приложение, что бы войти в него через любую соцсеть?
b
Я понимаю, что домохозяек вы привели как пример. Очень неудачный пример. Возможно, есть ЦА, где необходимо сделать вход через почту. Но такие проекты можно пересчитать по пальцам. Одной руки. Речь в посте о большинстве проектов
b
А зачем мне его регистрировать в ФБ????
b
ID:0
Рубрика #мюсли
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
Мне только авторизация нужна через ФБ
b
ID:0
Рубрика #мюсли
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
А, вы правы, нужно описывать
b
Так вы сравниваете разовую регистрацию в ФБ с разработкой и поддержкой регистрации по мылу? А если ваши письма в спам летят, или вообще не принимаются почтовиком? Не сталкивались с таким? Не поверю) там ещё больше танцев с бубном
b
ID:0
Рубрика #мюсли
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
Гугл вообще последние пару лет любит заворачивать письма. По итогу, авторзация через соцсети проще и надëжнее, для любого проекта
b
Вообще никаким) просто есть любители поспорить ради спора) ну, или показать, какие они молодцы, а другие не очень. Другого объяснения у меня нет
b
А где было написано, что только одна регистрация через гугл????
b
Перечитайте пост, там говорится о регистрации через соцсети, а далее гугл как пример одной из соцсети
b
Могу с уверенностью сказать, что прикрутить регистрацию через 3-4 соцсети можно МАКСИМУМ за день
b
Перечитайте начало поста. Там написано про соцсети, во множественном числе
b
ID:0
Рубрика #мюсли
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
А далее пример про гугл
b
Я вот перечитал комментарии. Вам несколько раз указали, что в посте речь о соцсетях вообще, а не только о Гугл. Не уходите в словоблудие пожалуйста. Разработка и поддержка регистрации через емэйл сложнее, чем добавить авторизацию через 3-4 соцсети. Про проблемы отправки писем я писал выше (их на самом деле больше, я только пару указал)
MJ
ID:0
Рубрика #мюсли
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
Привет всем
B'
ID:0
Рубрика #мюсли
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
В комментариях к прошлому посту отметились свидетели логина через имейл и пароль, мол, его сделать — 5 минут из опенсорсных либ, а вот с OAuth придется попариться. Я думал, что настолько субъективно мыслящих людей у меня на канале больше нет — оказалось, еще остались люди, которые любят переусложнять свои продукты (и в итоге либо не запускают, либо запускают никому не нужный переусложненный отстой).
Но ничего страшного, их я побанил, их больше нет, рациональность снова восторжествовала. А в этом посте я раз и навсегда объясню вам, почему логин через имейл и пароль для MVP — это смерть, а логин через соцсети — это кошерно.
Сразу отмечу, что люди, у которых "нет социальных сетей" и которым "не нравится логин через социальные сети" с огромной вероятностью не просто не ваша целевая аудитория, а это тот самый сегмент пользователей, которым никак не угодишь — этих пользователей надо обходить стороной, денег они вам не дадут, а головняка создадут. И вот уже первое преимущество делать социальный логин: вы отфильтровываете этих "неправильных" пользователей.
Но давайте посмотрим, что нужно сделать разработчику, чтобы подключить логин через имейл и пароль:
— Сохранять созданные учетки в базе данных
— Хранить у себя хеши паролей и обеспечивать безопасность хранения этих хешей
— Убедиться в надежности работы функций хеширования паролей и верификации хешей
— Обрабатывать ошибки неправильного пароля, попытки регистрации уже существующего имейла
— Реализовать флуд-контроль, чтобы пользователи не могли регистрировать тонны аккаунтов-ботов
— Реализовать верификацию имейла (свой SMTP сервер или платное стороннее решение)
— Реализовать восстановление пароля
— Ну и, собственно говоря, реализовать регистрацию и логин через имейл и пароль
Наверняка, я что-то еще забыл, а теперь давайте посмотрим, какое трение у пользователя, который хочет зарегистрироваться у вас в сервисе:
1. Человек зашел на сайт
2. Нажал "Зарегистрироваться"
3. Ввел свой имейл
4. Придумал пароль, который подходит подо все правила
5. Нажал "Зарегистрироваться"
6. Открыл почтовый клиент и подождал, пока придет письмо верификации аккаунта
7. Кликнул на кнопку верификации аккаунта
После этого пользователь наконец-то начнет пользоваться вашим сервисом. Каков сценарий последующего логина или логина с мобильных устройств? Поиск (или попытки вспомнить) пароля, возможно восстановление пароля, копипейст или ручной ввод длинного надежного пароля.
А теперь посмотрим, что нужно сделать разработчику, чтобы добавить логин через условный Гугл:
— Создать приложение в Гугл Клауде и получить идентификатор клиента
— Добавить на сайт компонент кнопки "Войти через Гугл" и дать ему идентификатор клиента
— Обработать на сервере создание учетки пользователя
Хм, а где все эти танцы с бубном вокруг верификации учеток, обработки ошибок, флуд-контроля или все тому подобное? Черт, да их нет! А как выглядит теперь трение пользователя, который хочет начать пользоваться нашим продуктом?
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
Для MVP может и да, но потом нужно будет добавить и вход через лог-пас, думаю
b
Для MVP может и да, но потом нужно будет добавить и вход через лог-пас, думаю
Речь только о МВП. Потом можно что угодно делать
b
Так с этим никто не спорит. Об этом в посте и речь)