P
Nice guy же, классика
Size: a a a
2021 January 27
P
Это ты ещё легко обошёлся)
A
P
Вот почему все такие алчущие по моим дикпикам?
A
забавно как ИП вычеркнулась из интернетов после фиаско с финалом
A
только бронн остался))
С
хахах
E
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. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
1. Человек зашел на сайт
2. Кликнул на "Войти через Гугл"
3. Человек выругался и ушел к конкурентам, ведь у него в Китае (вторая экономика мира) Гугл заблокирован
2. Кликнул на "Войти через Гугл"
3. Человек выругался и ушел к конкурентам, ведь у него в Китае (вторая экономика мира) Гугл заблокирован
С
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. Кликнул на "Войти через Гугл"
Вот и все. Теперь и думайте, что же проще реализовать, поддерживать разработчику — и что проще для пользователя, чтобы начать пользоваться вашим продуктом.
Надеюсь, в следующий раз, когда вы будете запускать свой новый продукт, вы начнете упрощать, а не усложнять всем жизнь: себе, разработчикам и пользователям. Выбирать авторизацию через имейл и пароль могут только садомазохисты, не иначе.
Я уже спрашивал, но раз уж такая тема началась, то уточню еще раз. Как на счёт входа без пароля через почту?
1. Ввёл почту
2. Получил письмо с кодом или ссылкой
3. PROFIT
4. ???
1. Ввёл почту
2. Получил письмо с кодом или ссылкой
3. PROFIT
4. ???
u
ID:0
Рубрика #мюсли
Мое сугубо личное мнение: абсолютно любое сообщество может стать лучше, введя более строгую модерацию за токсичность. Да, в первое время отвалится 10-20 процентов аудитории (которая все равно не платит, токсичные люди жадные). Да, Интернет побурлит про ограничение свободы слова.
Зато оставшимся 80-90 процентам людей можно будет начать дышать полной грудью. Сообщества, где никому не хочется оскорблять друг друга, где обратная связь всегда прямая и объективная, где никто друг друга не подкалывает — эти сообщества становятся приятной бухтой Интернета, куда хочется пришвартовываться снова и снова.
Таким, например, в свое время был Хабр. Таким является и наш ламповый чатик @borodutcher. Единственная проблема такого подхода — это поднятие уровня токсичности сообщества, когда появляются люди, что нарушают единственное правило "не токсичить" — и пытаются себя как-то оправдать. Таких нужно банить сразу же и без зазрения совести. Если банить вовремя, то токсичность поднимается лишь ненадолго и на незаметное чуть-чуть.
Да, это заглушение голосов определенной группы людей, которые хотят нести в сообщество зло. Да, это диктатура администраторов и модераторов сообщества и монополия на цензуру. Однако нарушители правил — это моральные преступники; единственное, что им нужно — это унижение людей вокруг и токсичность. Когда мы закрываем за решетку убийц, мы не кричим об ограничении их прав на митинги и собрания. Так же и тут — нет смысла жаловаться на ограничение права высказываться человеку, который использовал это право во вред.
А когда сообщество боится порицания Интернета за ограничение свободы слова, это сообщество необратимо скатывается в клубок токсичности. Сначала туда входят единицы, потом десятки, потом сотни токсичных элементов — и вот в сообщество нельзя скинуть свою фотку из отпуска без токсичных комментариев в ответ.
Заходите в @borodutcher. У нас нет токсичности.
Мое сугубо личное мнение: абсолютно любое сообщество может стать лучше, введя более строгую модерацию за токсичность. Да, в первое время отвалится 10-20 процентов аудитории (которая все равно не платит, токсичные люди жадные). Да, Интернет побурлит про ограничение свободы слова.
Зато оставшимся 80-90 процентам людей можно будет начать дышать полной грудью. Сообщества, где никому не хочется оскорблять друг друга, где обратная связь всегда прямая и объективная, где никто друг друга не подкалывает — эти сообщества становятся приятной бухтой Интернета, куда хочется пришвартовываться снова и снова.
Таким, например, в свое время был Хабр. Таким является и наш ламповый чатик @borodutcher. Единственная проблема такого подхода — это поднятие уровня токсичности сообщества, когда появляются люди, что нарушают единственное правило "не токсичить" — и пытаются себя как-то оправдать. Таких нужно банить сразу же и без зазрения совести. Если банить вовремя, то токсичность поднимается лишь ненадолго и на незаметное чуть-чуть.
Да, это заглушение голосов определенной группы людей, которые хотят нести в сообщество зло. Да, это диктатура администраторов и модераторов сообщества и монополия на цензуру. Однако нарушители правил — это моральные преступники; единственное, что им нужно — это унижение людей вокруг и токсичность. Когда мы закрываем за решетку убийц, мы не кричим об ограничении их прав на митинги и собрания. Так же и тут — нет смысла жаловаться на ограничение права высказываться человеку, который использовал это право во вред.
А когда сообщество боится порицания Интернета за ограничение свободы слова, это сообщество необратимо скатывается в клубок токсичности. Сначала туда входят единицы, потом десятки, потом сотни токсичных элементов — и вот в сообщество нельзя скинуть свою фотку из отпуска без токсичных комментариев в ответ.
Заходите в @borodutcher. У нас нет токсичности.
20 процентов аудитории которая не платит
а кто-то платит за чат бородача?
а кто-то платит за чат бородача?
A
Устрашение
A
Но вообще заседания суда публичные, и там можно в принципе снимать
A
Это конечно не суд на видео, но его ж могут и на суде попросить дать показания
С
в Linux-системах нашли уязвимость, предоставляющую root-права любому пользователю
Если быть точнее, то «дыра», найденная в sudo, касается вообще всех Unix-систем. С её помощью, злоумышленники могли получить администраторские права на компьютере, не проходя даже этап аутентификации:
https://tprg.ru/MlxD
Если быть точнее, то «дыра», найденная в sudo, касается вообще всех Unix-систем. С её помощью, злоумышленники могли получить администраторские права на компьютере, не проходя даже этап аутентификации:
https://tprg.ru/MlxD
С
Извинитесь, перед всем чеченским народом
С
И перед Рамзаном Ахматовичем непосредственно
