Не совсем понятно, почему OAuth рассматривается автором только в отношении социальных сетей. Этот механизм поддерживается и email-сервисами. Поэтому у меня на сайте есть кнопки «Войти без пароля через Mail.ru / Яндекс.Почту / GMail».
1) избавляемся таким образом от необходимость слать письмо «подтвердите вашу почту» (все ящики верифицированы таким образом по умолчанию)
2) убираем пароль
3) получаем дополнительную инфу, такую как имя
И эти кнопки пользуются популярностью — через них регистраций в несколько раз больше чем через социальные сети.
Конечно, от соцсетей есть дополнительные плюшки вроде аватарки, другой инфы, что позволяет сразу создать полноценный профиль. Но в статье речь только про авторизацию.
13. 404 страница. Мне не нужны дизайнерские фантазии. Мне нужно поле «найти на сайте» (ссылка протухла, видимо — материал перемещен, и я хочу его найти) и ссылка «На главную». Всё.
2. Неужели так сложно при нажатии «Вспомнить пароль» запоминать e-mail и подставлять его в это поле? Нигде еще такого не видел, и всегда приходится набирать дважды.
Спасибо за ваш развернутый комментарий выше.
Я остановился на варианте, когда время последнего визита становится полем пользователя, а класс для работы с друзьями содержит метод «Получить друзей», которому можно передать параметр «только онлайн», и он будет делать нужный джойн. То есть — такое односторонее нарушение инкапсуляции. Теоретически это плохо — если изза растущей нагрузки мне придётся хранить список онлайн юзеров в памяти — придётся переписывать и класс работы с друзьями. Надеюсь, такое время наступит не скоро.
У нас ActiveRecord, который позволяет использовать в том числе запросы забитые вручную. ORM в свое время показался не самыми гибким для развивающегося стартапа… (много раз приходилось менять схемы, и делать это надо было быстро, принцип бережливго стартапа).
Оно примерно так и хранится. Только время последнего визита лежит не в таблице пользователей, а в отдельной. А через год — может будет лежать в Редисе. Формат хранения друзей также может измениться. Поэтому хочу сделать так, чтобы класс Юзер ничего не знал про то, как хранятся его друзья, и как хранится его статус «онлайн», и он мог просто получать эти данные от двух независимых от себя сервисов. А как эти сервисы подружить между собой — вот в чем вопрос. При том что они не должны ничего друг о друге знать? Т.е. одним запрос тут никак не сделаешь, надо выбирать сначала всех друзей, потом проверять их отдельно через сервис «кто онлайн». А можно сэкономить своё время, и захардкодить более быстрое решение через один запрос с join.
Да, это не сущность в плане «Модель», а скорее некий сервис. В случае друзей — у него есть методы «Отправить запрос на добавление в друзья», «Принять в друзья», «Удалить из друзей», «Получить список друзей». В случае онлайна — «Получить список тех кто онлайн», «Узнать онлайн ли данный юзер» и «Поставить отметку времени (типа пинг = я онлайн)».
Очень интересует данная тема.
Никак не могу сообразить, как решить одну задачку в рамках правильной архитектуры. Есть допустим в проекте пользователи и две такие сущности: «Друзья пользователя» и «Кто онлайн». Отдельно работают замечательно, ничего друг про друга не знают. Хранятся и те и другие данные в mysql. Но если надо вывести тех друзей, которые сейчас онлайн — самое простое и быстрое решение это сделать выборку по двум таблицам (friends join users_online). Но её сделать нельзя, ибо «Друзья» ничего не знают про формат хранения онлайн-юзеров, онлайн-юзеры не знают про формат хранения друзей, а все остальные не знают ни того ни другого. Как быть?
Впервые агрегаторы социальных сетей в Рунете «придумали» еще в 2007 году, был такой стартап — bestpersons. Вы изучали его перед тем как создать свой? Анализировали причины, по которым он провалился?
Прежний «Лайк» — это «Лайк без эмоции» (без эмоциональной окраски или нежелание ей делиться).
А смайлы — это «Лайки с эмоциями». Они не отделены от лайка, и нажатие на эмоцию совершает также и «Лайк», но добавляет к нему некий смайл. Если рассматривать это так, то вытсраивание в ряд выглядит логично — всё это виды лайка, первый — без эмоции, остальные — с эмоциями.
1) персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных);
Пол, цвет волос… да даже выдуманный вами ник — относятся к вам прямо или косвенно. Если человек указал о себе любую информацию, например, что любит какой-то фильм — это тоже персональные данные?
При выводе альтернативных реакций снова дублируется опция “Like”. В итоге две одинаковые кнопки находятся на расстоянии 20px друг от друга. Это бессмысленно
Удивительно слышать подобное от человека, который утверждает что занимается интерфейсами.
Если бы я навёл на кнопку «Like» и мне выскочило окошко с вариантами, в которых нету варианта Like — я бы решил что эту функцию просто убрали, заменили на новые смайлы (а не добавили их к ней).
Обязательно ли считать префиксами каждое слово в наборе, или только последнее? Это к ситуации запроса «а б», которое генерирует длинные списки id.
Практическая польза видится только в случаях, если человек начал редактировать свой запрос и набирает новое слово в начале Подобные ситуации можно отслеживать и считать префиксом только текущее редактируемое слово, а все остальные слова в запросе — считать набранными до конца.
Тоже у себя пытаемся анализировать возвращенные письма, но у нас один noreply-адрес в заголовках Reply-To и Return-Path, и кроме сообщений о недоставке также приходят всякие автоответы. Из-за этого приходится разбирать каждый bounce скриптом — на предмет того это ошибка или автоответчик. А если делать разные, то как я понимаю, автоответы будут идти на адрес из Reply, а недоставка — на Return?
Да и вытягивание из текста сообщения о недоставке самого адреса получателя — задача нетривиальная, т.к. у всех почтовиков свой формат и они иногда меняются. А ваш способ зашить айдишку получателя прямо в адрес, на который приходит письмо, решает эту проблему.
Если не хватило пару минут на последнюю задачу, то никто и не напишет? Нужно было решить все?
1) избавляемся таким образом от необходимость слать письмо «подтвердите вашу почту» (все ящики верифицированы таким образом по умолчанию)
2) убираем пароль
3) получаем дополнительную инфу, такую как имя
И эти кнопки пользуются популярностью — через них регистраций в несколько раз больше чем через социальные сети.
Конечно, от соцсетей есть дополнительные плюшки вроде аватарки, другой инфы, что позволяет сразу создать полноценный профиль. Но в статье речь только про авторизацию.
2. Неужели так сложно при нажатии «Вспомнить пароль» запоминать e-mail и подставлять его в это поле? Нигде еще такого не видел, и всегда приходится набирать дважды.
Лексикон, как у бабушки из соседней квартиры, для которой любой кто может переустановить ей винду уже хакер))
Я остановился на варианте, когда время последнего визита становится полем пользователя, а класс для работы с друзьями содержит метод «Получить друзей», которому можно передать параметр «только онлайн», и он будет делать нужный джойн. То есть — такое односторонее нарушение инкапсуляции. Теоретически это плохо — если изза растущей нагрузки мне придётся хранить список онлайн юзеров в памяти — придётся переписывать и класс работы с друзьями. Надеюсь, такое время наступит не скоро.
Никак не могу сообразить, как решить одну задачку в рамках правильной архитектуры. Есть допустим в проекте пользователи и две такие сущности: «Друзья пользователя» и «Кто онлайн». Отдельно работают замечательно, ничего друг про друга не знают. Хранятся и те и другие данные в mysql. Но если надо вывести тех друзей, которые сейчас онлайн — самое простое и быстрое решение это сделать выборку по двум таблицам (friends join users_online). Но её сделать нельзя, ибо «Друзья» ничего не знают про формат хранения онлайн-юзеров, онлайн-юзеры не знают про формат хранения друзей, а все остальные не знают ни того ни другого. Как быть?
А смайлы — это «Лайки с эмоциями». Они не отделены от лайка, и нажатие на эмоцию совершает также и «Лайк», но добавляет к нему некий смайл. Если рассматривать это так, то вытсраивание в ряд выглядит логично — всё это виды лайка, первый — без эмоции, остальные — с эмоциями.
Пол, цвет волос… да даже выдуманный вами ник — относятся к вам прямо или косвенно. Если человек указал о себе любую информацию, например, что любит какой-то фильм — это тоже персональные данные?
Удивительно слышать подобное от человека, который утверждает что занимается интерфейсами.
Если бы я навёл на кнопку «Like» и мне выскочило окошко с вариантами, в которых нету варианта Like — я бы решил что эту функцию просто убрали, заменили на новые смайлы (а не добавили их к ней).
Практическая польза видится только в случаях, если человек начал редактировать свой запрос и набирает новое слово в начале Подобные ситуации можно отслеживать и считать префиксом только текущее редактируемое слово, а все остальные слова в запросе — считать набранными до конца.
Да и вытягивание из текста сообщения о недоставке самого адреса получателя — задача нетривиальная, т.к. у всех почтовиков свой формат и они иногда меняются. А ваш способ зашить айдишку получателя прямо в адрес, на который приходит письмо, решает эту проблему.
Большое спасибо за то, что поделились опытом!