последующие действия -
если ваши пользователи не могут вспомнить, что они подписались ранее, ну, в общем, удачи им в общем;)
так же, как вы описали, яЯ планирую предоставить пользователям возможность связывать дополнительные учетные записи после того, как они вошли в систему тем или иным способом.
но что касается перекрестной проверки, вы можете сделать только так много.многие API социальных сетей действительно предоставляют адреса электронной почты (после того, как вы подключились через OAuth), но они могут быть доступны только в том случае, если пользователь решил опубликовать свой адрес, что не гарантируется.
также не гарантируется, что пользователь использовал один и тот же адрес электронной почты для каждой учетной записи социальной сети, поэтому даже если вам удастся получить адрес, он может вам или не понадобится.
наконец, если вы обнаружите совпадающие адреса электронной почты с помощью таких средств, было бы целесообразно предложить пользователю связать учетные записи, а не предполагать, что он / она хочет, чтобы это было сделано автоматически.Некоторые люди любят поддерживать несколько личностей.т. е. «похоже, что вы также зарегистрированы в твиттере - хотите ли вы связать свои учетные записи? это сделает вашу жизнь достойной жизни».
вы можете подумать о том, чтобы предлагать стимулы для привязки учетных записей пользователей или предоставленияадрес электронной почты (конечно, до вас, чтобы выяснить, что это может быть, исходя из функциональности вашего веб-сайта).
решение, над которым я работаю, на стороне базы данных, - это поддерживать несколько учетных записей, а затем, если ссылкаинформация обнаруживается различными способами, указанная ссылка указана в справочной таблице.альтернативный вариант - как только вы найдете ссылку, попытайтесь объединить все соответствующие записи для нескольких учетных записей в одну сущность учетной записи - все, что я могу сказать об этом последнем подходе, - это то, что я буду делать это с осторожностью, поскольку в зависимости от уровня сложностина уровне активности пользователя и сложности схемы вашей базы данных.
в моем (умственном / фактическом) пространстве имен пользователь, который регистрирует старомодный способ, имеет «стандартную» учетную запись, а тот, кто использует социальную сеть, -счет псевдонима.затем цель состоит в том, чтобы определить, куда должен указывать псевдоним, то есть создать поиск таким образом, чтобы последующий вход в систему с помощью либо означает получение соответствующей информации для обеих учетных записей (с предпочтением дляотображение личных данных для «стандартного» аккаунта).
кстати, я понял, как заставить OAuth в Твиттере вести себя со времени моего последнего поста - вы можете посмотреть другие мои ответы, если вам интересно.
JB
привет Мэтт,
Я сейчас работаю над той же проблемой.
при условии, что пользователь начинает с обычной учетной записи на сайте (что не , обязательно можно предположить, если он видит все симпатичные кнопки «подключиться к сети XXX» !!!), вы можете использовать либоOAuth или javascript API (facebookConnect или @anywhere - еще не до конца разобрались с последним, и я не уверен, что рекомендую его, так как не думаю, что он предоставляет столь же богатый API, как и библиотеки на сервере), чтобы войти вдругие сайты.
API должны возвращать определенную информацию после успешного входа / перенаправления из социальной сети, такую как идентификатор пользователя и токен доступа, которые вы можете затем сохранить в своей базе данных в некотором качестве, связывая вашфактический пользователь приложения с идентификатором социальной сети.
когда пользователь возвращается на сайт, вы можете
1 проверить файлы cookie, установленные службами социальной сети (различные схемы обычно проверяютподпись, основанная на хэше sha1 или md5 данных вашего приложения - под которыми я подразумеваю данные, которые вы получаете, когда выЗарегистрируйте свое приложение с помощью Twitter / Facebook, обычно с ключом потребителя, идентификатором приложения и т. д. - с полученными файлами cookie), чтобы вы знали, что пользователь вошел в социальную сеть
2 и найдите ассоциацию входа в базу данных, как описановыше
3 войдите в систему вашего пользователя вручную на основе
предположение, что фейсбук / твиттер
соединение безопасно.
предостережение: это так же безопасно, как ваш
реализация (или так же безопасно, как
Facebook / Twitter реализации, если
ты предпочитаешь ...)
хотя в твиттере OAuth нет
в настоящее время, кажется, работает совершенно правильно,
их общее описание
процесс довольно информативный:
http://dev.twitter.com/pages/auth
удачи.
J