Pull to refresh

Comments 71

А в серверной части происходит какая-то проверка присланных данных?
Естественно, это нужная вещь. Для Facebook в примерах проверка есть, для Вконтакте — нет.
И какая же у вас проверка у фейсбука? Судя по примеру в ваш скрипт передаётся токен и айди пользователя, т.е. если у меня есть своя аппликация в фейсбуке, то у меня этих токенов просто обзавались, и я свободно залогинюсь под любым пользователем моей аппликации. Вместо токена, нужно передавать в скрипт зашифрованный sighned_request который можно рашифровать только секретным ключем именно вашей аппликации.
Проверка была никудышная, в этом вы правы, но не в том месте некудышная. Токен уникален для приложения, и попытка использовать токен одного приложения в другом провалится.

Проблема в серверном коде, который при передаче ему валидного access_token верит, что переданный ему uid соответствует access_token'у, что может быть и не так. В данном случае можно передать uid администратора, и заполучить его права.
попытка использовать токен одного приложения в другом провалится.

Вы абсолютно не правы. Токен другой апликации без проблем можно использовать где угодно, так как на самом деле, при запросе данных из фейсбука, ничего кроме этого самого токена не используется! И абсолютно не важно, что этот токен не принадлежит именно вашей апликации, главное чтоб он был валидный сам по себе.

Проблема в серверном коде, который при передаче ему валидного access_token верит, что переданный ему uid соответствует access_token'у, что может быть и не так. В данном случае можно передать uid администратора, и заполучить его права.

А это уже совсем жесть. Дыра на дыре.
Вам абсолютно не нужно передавать айди пользователя в скрипт, так как получив токен и сделав запрос в фейсбук /me, вы получите айди пользователя чей токен вы проверяете.

Яб вам порекомендовал познакомится поближе с документацией по Facebook Graph API, и глядишь одним дырявым скриптом в интернете станет меньше.
Вам так же рекомендую подробнее изучить документацию, и узнать, что access_token — уникальная последовательность данных, сопоставляющая идентификатор пользователя и идентификатор приложения. Имея на руках access_token, возможно узнать как и пользователя, которому он был выдан, так и приложение. Достаточно сделать вызов на /app (аналогично вызову на /me для получения пользователя). Необходимость в подписании access_token'а в данном случае отпадает.
UFO landed and left these words here
UFO landed and left these words here
Будет потрясающе, если вы расскажете, какие из них лишние.
Меня пара окон всплывающих так же раздражает.
Для этого я бы все же разнёс по разным кнопкам регистрацию, как, например, сделано у нас на сайте (правда мы не отказывались от варианта с регистрацией на почту).

Скрин для наглядности:

Я не настаиваю, кто как считает удобнее. В топике об обработке нажатия на кнопку — ни слова. И это — упущение. Добавил оба варианта.
Весь смысл статьи был в том, чтобы вход был неназойливым, то есть, если пользователь уже авторизовал доступ вашего сайта к своим данным на OAuth провайдере, то никакие кнопки нажимать уже не надо. А у вас по-прежнему надо.
а что делать, если нам еще нужен Email? фб его отдает, а вк нет.
Судя по ответам на мой вопрос в Q&A, идеального решения нету.
Я для себя выбрал не сильно навязчивые, но все же заметные напоминания, что если заполнить мыло, то за это бонус на сайте дадут. А то получается, что юзер из вконтакта не имеет никакого средства организации автоматизированной обратной связи…
у меня на сайте, пользователи из вк из за этого идут лесом. Т.к. все норм провайдеры отдают мыло, а вк у нас самой хитроумный.
Считаю это тоже не совсем правильным, т.к. искуственно заужаете аудиторию — не всем такой подход будет подходящим. Лучше позволять зарегиться через вк, но напоминать о необходимости (и мотивировать) мыло ввести.
так они то от этого и уходили, чтобы только к телу привязка была. Зачем же возвращаться?
Твиттер, кстати, тоже мыло не отдает. Вот нормальный он после этого? :)
я там и там не сижу, так что они оба для меня…
Если что — у пользователя ВКонтакте в принципе может не быть никакого е-мэйла, только телефон в качестве логина.
не все пользователи готовы вбивать свой тел на всех сайтах, где они регаются.
Не понял, о чем вы. В данный момент необходимое условие для регистрации ВКонтакте — наличие мобильного телефона, а мыло не запрашивается вовсе.

Даже если бы ВК мог возвращать внешним сервисам адрес почты — вам все равно пришлось бы обрабатывать тот случай, при котором ничего не вернется.
сейчас да, но до этого требовался Email они ушли от этого добровольно принудительным порядком.

Какую публичную информацию отдавать другим сайтам, можно настроить один раз, как на яндексе и все. Тут все дело в политике вк.
в принципе может не быть
Только я прочёл как «в принципе не может быть» и озадачился? :)
Если быть точнее ваш сайт у пользователей идет лесом.
Вы видимо не в курсе, что для регистрации во вконтакте мыло не обязательно, и у некоторых его вобще нет.
Раньше, помнится, некоторые пользователи регали мыло где-нибудь на мэйле или яндексе только для того, чтобы зарегаться вконтакте. Они даже не знали такой сущности как e-mail по сути. Теперь их от этого избавили.

Не слишком ли вы жёстко с самым (одним из?) популярным ресурсом России?
Разве secure.sendNotification не работает, если в VK.init передать scope: notify?
В любом случае, если вдруг VK.init не умеет его обрабатывать, all.js лучше скопировать, подправить и отдавать от себя, потому что VK любит его ломать полностью.
Методы secure.* не для сайтов — они для Standalone приложений…
можно использовать как вариант если весь контент на сайте подгружается через ajax.
А если клик по ссылке == перезагрузка страницы, имхо, не очень хороший вариант.
дополнительные 2 запроса на разные адреса. Хоть и небольшие.

+ еще один вариант: возьмем обычный офис — все соц.сети заблокированы. Сайт читаю, а ничего сделать не могу.
Так что обычную авторизацию нужно оставлять в альтернативу таким.
лучше предлагать на выбор пользователю
Не понял я как взаимосвязаны 2 лишних запроса на разные адреса и ajax-овость контента на сайте честно говоря)

А насчет заблоченных сетей — согласен, что от традиционной регистрации пока рановато уходить, хотя даже по опыту внедрения только vk и fb авторизации (без остальных провайдеров), кол-во регистраций через обычный email очень мало…
И не только когда заблокированные сети.
Это вообще в принципе ущербный вариант — ущемлять каку-либо часть пользователей.

Имхо работать надо в другую сторону — не просить регистрацию где она не нужна, не просить данные, кторые вам ни к чему.
Увы, соцсети предоставляют данные, которые мне даром не сдались. То есть пользователь видит по дефолту что-то вроде «разрешить приложению использовать ваши ФИО и день рождения?» и запрещает из страха, хотя они мне не нужны, нужен только id для регистрации и последующей аутентификации.
Вы правы. Именно поэтому мне и не нравится подобные однобокие решения. Обязательно надо оставлять юзеру возможность максимально простой регистрации — логин+пароль. Ну и стремиться, использовать регистрацию только в интересах самого пользователя, то есть когда это действительно необходимо, но даже и тогда — как вариант, а не принуждение.
К примеру, подает человек объявление, одно единственное объявление в жизни на впервые увиденном сайте. Нафига мне его мыло? И вообще что-то. Пусть подает, я ему предлагаю вариант: можно придумать пароль к объяве и тогда сможешь редактить его потом, а можно зарегиться — тогда будет кабинет и все дела, ну а не хочешь — как хочешь, тогда оно твое пока кука не умрет. Смысл мне в мертвых душах?

P.S. Честно говоря, вообще непонятно кто тут так заплюсовал «это». Далеко не новость, а как реализация — кривовато и страшненько.
Емейл и пароль — далеко не самая простая регистрация. Пароль, как известно, лучше придумывать уникальный, запоминать кучу паролей тяжело, особенно если вдруг понадобится доступ откуда-то из другого места. Для решения этой проблемы был придуман OpenID, и многие им пользуются для входа. Но OpenID (в том числе даже Gmail'овский, LJ'шный и тп) есть не у всех. А либо Facebook, либо Вконтакте есть у преобладающего количества пользователей. Мало того, у многих пользователей Вконтакте и адреса электронной почты-то нет, так как в данный момент для регистрации достаточно номера мобильного телефона.

Регистрация емейл-пароль обычно требует подтверждения емейла, что уже делает её более трудоёмкой, нежели вход через соц. сеть.
Вот сколько раз не пытался войти через OpenID Гугла — ни разу не получалось. Я даже не уверен то ли я ввожу в поле ввода. Как-то гугл по google openid неоднозначную информацию даёт.

Но в любом случае согласен, что надо стараться давать максимальную свободу пользователю для регистрации/аутентификации и не требовать регистрации если она не нужна для предполагаемого сценария использования.

Хорошие регистрации не требуют, а пускают сразу после ввода ненавязчиво время от времени предлагая подтвердить e-mail, для ясных целей.
Уважаемый, вы где в моем тексте слово емейл увидели?
У меня было «логин+пароль».

А что касается регистрации вообще, то вот там когда она нужна, желательно давать как можно больший набор, на всевозможных любителей. Чем шире выбор тем лучше. Это как с платежными системами — хуже не будет.
При использовании описанного варианта тоже совершенно не обязательно требовать от пользователя регистрации. Например, посмотреть и поискать можно без регистрации. А вот совершить какое-либо действие она уже нужна.

Если бы это была доска объявлений, и не требовалась бы защита от ботов, то по вашему варианту можно вообще не применять никакую регистрацию. Ну, или сделать её опциональной, например, для возможности впоследствии редактировать объявление.
Ботам регистрация не помеха. Вернее помеха, но небольшая.
Вы повторяете ровно то, что я сказал, но как-будто возражая.
Либо вы невнимательно читаете, либо я чего-то не понял.
Можно использовать в обоих случаях. В примере сделано с расчётом на первый вариант, но не отправлять при перезагрузке страницы запрос на авторизацию — возможно и легко.
Наконец-то понял о чём шла речь)
Можно же и у себя сессиию хранить чтобы каждый раз не посылать запросы авторизации.
Было бы неплохо, если бы оно предупреждало, что будет спамить твою стену. Я по началу решил, что просто входишь и всё, а оно действия на стену транслирует.
Оно предупреждает. И предлагает даже выбрать область видимости своего спама (группа пользователей, либо только себе), либо вообще отказаться от возможности постить от лица пользователя.
Классно вроде.
А как происходит валидация пользователя на серверной стороне?
Пардон, уже нашел.
Для вконтакта можно не мучаться с Localhost, добавляем запись dev.mydomain.com 127.0.0.1 в system32/drivers/etc/hosts, вконтакте в качестве урла указываем dev.mydomain.com и все.
А разве он допускает одновременно использовать dev.mydomain.com и mydomain.com?
Да, все поддомены указанного домена могут работать по одному ключу.
В опере не прокатывает, приходится дополнительно добавлять в настройках браузера «Безопасные внутренние узлы», иначе блокирует кросс-доменные запросы.
Это уже каждый решит сам для себя, делать выход или нет, я тут описываю только вход и только клиентскую часть.
еще бы как-то объяснить это владельцам форумов у которых даже поиск закрыт для гостей…
… таких надо «мочить в сортире» ©
UFO landed and left these words here
«Не трогай, пока работает». Вконтакте разработчикам никаких уведомлений не присылал, только рядовым пользователям.
А чем это отличается от уже несколько лет обмусоливаемых способов входа через соц.сети а так же чем это лучше логинзы?
Отличие от уже несколько лет обмусоливаемых способов входа через соц.сети:
пользователю для повторного входа (логина) на наш сайт не нужно совершать вообще никаких действий

Это лучше логинзы хотя бы тем, что:
— не требуется нажимать кнопки 4 раза, чтобы зарегистрироваться, а только один раз;
— не выдаёт диковинных сообщений об ошибке при попытке войти фейсбуком и сохранить приватность своего емейл адреса:
Возникли следующие ошибки:

Неверно заполнено поле: Email!
Неверно заполнено поле: Логин!
Логин: app+3g8bjemte317kenol1785fc238a6c52a65a894716d925953b
Email: app+3g8bjemte3.17kenol.1785fc238a6c52a65a894716d925953b@proxymail.facebook.com
Завист от целей…

Например мне не нужен на сайте кто попало. А кому интересен мой контент и(или) услуги — тому не затруднительно ввести мыло / пароль.
За то лояльность моей аудитории будет на порядок выше «кого попало из вконтакта вошедшего за один клик».

И как вы считаете, зарегистрировать почту на бесплатном сервере проще или тяжелее, чем аккаунт Вконтакте и Фейсбуке? Что лучше поддаётся автоматизации и подвержено массовому приходу ботов?
Лояльность аудитории сильно падает, если ботов среди остальных пользователей много.
Ваше понимание влияния сложности регистрации на лояльность пользователей очень примечательно, могу лишь посоветовать вам добавить несколько каптчей, требовать множество личных данных, добавить в регистрацию задачи на сообразительность, валидировать не только адрес электронной почты, но и банковскую карту. Тогда пользователи, ну по крайней мере те, кто смогут пройти этот квест, точно будут очень лояльными. Но их будет очень мало.

В начале статьи я упомянул stackoverflow. Как вы считаете, аудитория к ним лояльна или совсем нет? У них тоже вход и регистрация в один клик. Какие видите отрицательные стороны в их подходе?
Прекрасно, но как дальше работать с такой аудиторией? Например, если человек оставил почту, ему на нее можно прислать уведомление о каком то событии (приход нового сообщения в личку на нашем сайте, например).
Что даёт вход-регистрация через соцсети, кроме аутентификации? Какие возможности по дальнейшей работе с этими людьми?
Обсуждается выше веткой. Если есть потребность отправлять смс или емейл уведомления — спрашивать дополнительно. При регистрации емейлом, например, телефон человека вы не получите, то есть смс уведомления отправлять не сможете.
Вход-регистрация через соцсети позволяет пользователю один раз залогиниться Вконтакте на любом компьютере, и потом просто заходить на сайты, без необходимости помнить свой пароли на них все.
Дальнейшие возможности работы с этими людьми точно такие же, как и при любой другой регистрации, только в данном случае она менее затруднительна для пользователя.
Спасибо за развернутый ответ
Вот этого момента про пароли я недопонимаю. Т.е. если юзер забыл или потерял пароль от контакта, то все — на наш сайт он тоже уже не попадет?

Еще не очень понятно — как мне его связывать с моей внутренней таблицей пользователей, учитывая что разные юзеры в том же стековерфлоу могут логиниться через разные системы.

Если человек забудет свой номер телефона или логин-пароль на почту, то он не сможет восстановить пароль от вконтакте.
Если человек забудет своё имя и номер паспорта, и где паспорт лежит, он не сможет восстановить SIM-карту.
… можно продолжать вечно.
Вконтакте и подобные специально сделаны так, чтобы пользователь не уходил, не забывал и не терял.

А топик посвящён тому, как сделать вход удобным. Никто не мешает вам дополнительно спросить номер телефона пользователя и/или адрес электронной почты (или что-то ещё) для нужд восстановления пароля, и сделать вход ещё и надёжным.
если человек оставил почту, ему на нее можно прислать уведомление о каком то событии

Поубивал бы… :) Серьезно, если я оставил почту, чтобы восстанавливать пароль, то неожиданные уведомления мягко говоря лишни. Вот после регистрации предложить пользователю «Если хотите получать уведомления — введите свою почту и подтвердите её» — это нормально. В конце-концов галочка «Я согласен получать уведомления».
Only those users with full accounts are able to leave comments. Log in, please.