Как стать автором
Обновить

Комментарии 33

Не совсем в тему, но если на сайте есть авторизация через такие сервисы, то предпочитаю уйти с сайта.
Потому как боязно — вдруг пароль уведут.
Разбираться как это может случиться — неохота, случаи то разные бывают.
Пока пароль не введен куда-нибудь — вряд ли уведут :)
Чушь полная. Никто не просит вводить пароль, просят авторизоваться на mail.ru, а response не содержит пароль.

> Разбираться как это может случиться — неохота
Вот в этом основная проблема толпы — никто не хочет разбираться, но комментарий оставить обязаны все!
Да, я представитель толпы :)
Толпа тоже имеет право заявить о своих мнениях и страхах.
В конце-концов 90% сайтов сделано для толпы, а не для тех кто хочет/может/думает что умеет/умеет разбираться.
У вас получается полуобразованная толпа. Слышал звон, да не знаю где он.
А ведь для большинства пользователей это очень удобный механзим авторизации. Плюс обычно авторизация через соц. сети не единственный вариант, оставляют и обычную регистрацию.

И вообще прикольная логика — у меня пароль уведут, уйду я с сайта. Вообще в интернет ходить опасно, там вирусы.
Что толпа делает на Хабре??? О_о
Что чушь — согласен. Но сознательно иду на поводу страха.
Предпочитаю перебдеть, чем недобдеть, в данном случае.
Один раз прочитать, что это и как работает — эффективнее, чем бояться всю жизнь и сознательно идти на поводу у страха, дорогой Представитель Толпы.
Сказочный долбоёб!
Спасибо за «долбоёба», рад познакомиться с умным человеком.

Могу ли я на своём сайте сымитировать страницу логина вконтакте или майлру, и предлагать «типа авторизоваться через них», воруя тем самым пароли?
Может ли кто-либо сделать тоже самое без моего (вашего) ведома, взломав сайт и сделав такую фейковую страницу, и некоторое время воруя пароли?

Многие ли смотрят (из нас, из толпы, а не из вас — «недолбоёбов»), действительно ли попали на страницу авторизации майлру?

Как-то страшно далеки «недолбоёбы» от толпы.

З.Ы. Чёт мнение о контингенте хабра совсем упало, после плюсов за комментарий «Сказочный долбоёб».
Даже если вы не авторизованы на фейсбуке, майле или контакте, то вам предложат ввести логин и пароль на страничке с адресом https://*.networkname/… и сами сети по несколько раз на дню убеждают пользователей перед вводом своих данных проверять адрес страницы.
Если бы разобрались в том, как работает данный способ аутентификации (авторизации), то поняли бы, что он как раз для того и был разработан, чтобы никто и никогда свои пароли нигде не светил. Это, с позволения сказать, «беспарольный» способ аутентификации. Если при таком способе сервис (какой-нибудь Mail.ru) начинает просить пароль, это может означать 2 вещи:

1. Вы не залогинены на данном сервисе, поэтому прежде чем через него аутентифицироваться на другом ресурсе, вам нужно аутентифицироваться сначала на нем самом.

2. Вы попали на фишинговый сайт, который скорее всего будет эмулировать ситуацию, описанную в 1-ом пункте.

В независимости от того, какой у вас случай, прежде чем вводить пароль, надо смотреть на текущий домен. В конечном счете человек всегда сам несет ответственность за то, где и когда он вводит свои пароли. Базовое образование пользователей (даже пусть и толпы) еще никто не отменял.

Но, опять же, на всех сайтах, использующих аутентификацию через сторонние ресурсы, как уже тоже было сказано выше, как правило имеется и обычный способ зарегестрироваться с логином и паролем.
Между прочим так думают многие пользователи, но думаю ситуация скоро изменится, ведь эта авторизация становится все более распространенной. Один из страхов я описал в статье.
И я о том же.
Что удобна такая авторизация — факт.
Что станет повально-массовым такой способ — вряд ли.
В следующей статье хотелось бы увидеть авторизацию через google-аккаунт
Следующим будет фейсбук, а потом небольшое возвращение к контакту, затем твиттер. Обязательно напишу про гугл, но в моей ситуации он почти бесполезен, так как используется лишь незначительной частью аудитории сайта, на котором я это все делаю.
Для пользователей из социальной сети МойМир я решил выделить логины вида «mm-20цифр». Да, именно 20-тизначное число в качестве айдишника, по запарке не сделайте приведение к обычному целому.

Проще делать составной ключ уникальный user_uid с mail.ru к примеру и sid поле с подписью mail.ru Как результат если вы подключите еще один сайт по oauth у вас не будет проблем с поиском пользователя.
Зачем мне лишнее поле в базе? Для меня проще запретить регистрацию аккаунтов вида mm-. Сайтов подключено уже три, каких бы то ни было проблем я не испытываю. Ну тут как говорится на вкус и цвет, я показываю лишь пример реализации.
Затем что это проще и логичнее, чем делать странные ограничения.
Не забудьте, пожалуйста, про OpenID.
Мне больше нравится мысль настроить универсальный вход через OAuth/OpenID и для добавления нового провайдера останется только добавить несколько файлов драйвера в пару строк (УРЛы, public_key, secret_key и т.д.). Не придется подключать километр чужих скриптов.
Да, если бы все провайдеры авторизации делали все унифицировано и по стандартам… Кстати, следующая статья про OAuth и ВКонтакте, примерно через 2 дня.
Не сильно глубоко еще ковырял, но Google/VK/FB/Github подключал нормально и достаточно легко. Были затупы с Яндексом, но из-за нехватки времени отложил в сторону, не перепроверял с тех пор.
Для рельс omniauth это делает.
Да в принципе в любом уважающем себя фреймворке есть нужные модули, остается только их собрать в свой Auth. Суть в подходе — не объединять имеющееся разное, а использовать единое универсальное (возможно, с допилом, куда уж без этого).
Единого универсального на уровне отдельных сервисов никогда ни в чем не будет (даже если все начнут использовать oauth), это жизнь. А универсальное на уровне библиотеки построить в целом не сложно и этого хватает с головой. Тот гем который я упомянул так и работает. Вы добавляете нужные параметры для нужного провайдера и этого достаточно. Естественно это работает если внутри самого гема есть поддержка соответствующующего сервиса (хотя дописать свою стратегию очень легко).
Пока mailу не покажешь, что у тебя есть файлик receiver.html, авторизация не будет работать, насколько я помню.

Функцию sign_server_server я немного подправил, добавив проверку того, чтобы ключ элемента массива не был равен 'sig'.
Лучше перед циклом писать unset($request_params['sig']), еще лучше перед ksort даже, потому что там во внутренней реализации всё равно цикл.
В целом, весь код, который можно вынести из цикла, лучше всегда выносить.
Ну и рекомендую на будущее обратить внимание на функции работы с массивами, чтобы лишний раз вообще свои циклы не писать. Читать тут: php.net/manual/en/ref.array.php
И еще вот: php.net/manual/ru/function.http-build-query.php — здесь читать первый комментарий от анонимуса.

На сегодня урок закончен :)
Ай, quote неправильно написал :(
В общем, третья строчка комментария — это цитата из топика.
Спасибо, но ансет делать не хочется по причине того, что массив с майловскими переменными хотелось бы хранить всегда в исходном виде. По поводу http_build_query — анонинумус наверное был не в курсе, что разделитель задается в php.ini и от того куда мы в дальнейшем посылаем запрос это никак не зависит.
Массив в функцию в данном случае передается не по ссылке. Соответственно, передав его в эту функцию, внутри мы будем работать с его копией, а следовательно сделав с ним что угодно в этой функции, снаружи он не изменится.
В качестве домашнего задания предлагаю проверить это на практике и заодно попробовать принимать его в функции по ссылке и оценить разницу.

По поводу http_build_query: доступ к php.ini есть не всегда. Остальную часть про «куда в дальнейшем посылаем запрос» не понял :(
Извиняюсь, рабочий код у меня немного отличается от примера, я нигде не упомянул этого. Анонимус на пхп.нет столкнулся с проблемой отправки запроса на томкат-сервер, однако разделитель задается с mode PHP_INI_PERDIR, т.е. его можно указать в .htaccess-файле, а представить ситуацию, когда у нас нет доступа даже туда, — очень сложно.
Да и массив с майловскими перемененными обычно нигде не нужен после того, как авторизовал пользователя. Не надо его хранить в надежде на будущее. Когда понадобится — тогда и будете хранить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории