• Обзор Twitter-клиентов для Windows Phone 7
    0
    Извиняюсь, пропустил как-то на рефлексах совсем. Более того когда писал коммент — специально поискал по вашим ответам — нет ли там упоминаний. И пропустил повторно. Видать у меня все еще понедельник…
  • Обзор Twitter-клиентов для Windows Phone 7
    0
    Эмм, извините за оффтоп, но где вы это написали?
  • Обзор Twitter-клиентов для Windows Phone 7
    +1
    ушел с мехдоха на рови т.к. понадобились списки аккаунтов — в мехдохе не нашел их вообще… Рови сильно комфортнее, переход вообще не заметил, только функций прибавилось.
    Попробуйте — может так проще будет.
  • Интервью с владельцем ботнета
    +2
    когда 90% биткойн майнеров в одних руках — вроде как можно просто поломать систему, нарисовав себе бабла =)
  • Интервью с владельцем ботнета
    +1
    ого, хабр по-своему любит авторов с большой кармой.
  • Интервью с владельцем ботнета
    +10
    Оператор совсем не русский, не надейтесь =)
    Если читать весь тред ( а за Iama прикольно следить — там есть крутые iama-топики) — там реддиторы пытаются его деанонимизировать и очень похоже что он немец =), читать отсюда www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet_operator_ama/c4g2rrr

    И новость немного [:||||:]
    Если никто особо не читает реддит — тогда советую обратить внимание еще на один iama

    IAM Sebastian Thrun, Stanford Professor, Google X founder (self driving cars, Google Glass, etc), and CEO of Udacity, an online university empowering students!


  • RIM продаёт самолёт и инвестирует в BlackBerry-разработчиков
    0
    И сколько предполагается будет скидка за телефон стоимостью 21000 рублей?
    А trade-in — если только в тот же модельный ряд, потому как дисплей люмии сильно отличается от того же htc.
    И да — яиц не хватит, т.к. такое действие подорвет их финансовый отчет. А это они на фоне остальных убытков и факапов себе вряд ли смогут позволить. Ну и просто — яиц уже давно нету, к сожалению.
  • RIM продаёт самолёт и инвестирует в BlackBerry-разработчиков
    +2
    Это такое же вранье как и в отношении WP7. Про 7ку говорили такую же маркетинговую хрень.
    Я лично буду целенаправленно вести анти-WP8 политику в своем окружении. И несмотря на то, что я зарабатываю деньги вокруг платформы MS, я никому не посоветую мобильную платформу WPx, пока MS не разрулит откровенное кидалово с WP7. Если не разрулит — ну что ж, ариведерчи мобильной платформе.

    И не надо надеяться на скудоумие консьюмеров — в этих 3% были кинуты в основном early geeks и энтузиасты — они не забывают.
  • RIM продаёт самолёт и инвестирует в BlackBerry-разработчиков
    +1
    Нокиа обещала.
    Мс обещала длинный жизненный цикл платформы и девайсов. Из серии — если в андроиде обновления должен выпускать вендор и он на это забивает, то тут все ванильное будет доступно.
    Жизненный цикл платформы длиной в 2 года — это чушь и кидалово. И это именно так, несмотря на все скольскожопые катания евангелистов со словами — ну мы не обещали ваще ничего.

    Это какой-то «аршавин от мира IT» — это типа ваши проблемы что мы не оправдали ваших надежд.
  • RIM продаёт самолёт и инвестирует в BlackBerry-разработчиков
    +3
    Блажен кто верует… После такого кидалова энтузиастов ( изначально было обещано что будут Vanilla updates, и на WP8 будет 100% апдейт люмий) — я всерьез задумался об iOS, несмотря на мою нелюбовь к политике Apple.

    Нельзя кидать 3% рынка в надежде что на следующую версию они снова к тебе прибегут. Да, после всего я стал анти-энтузиастом WPx — всем знакомым «отсоветовал» смотреть в сторону WP платформы.
    И думаю я не один такой.
  • RIM продаёт самолёт и инвестирует в BlackBerry-разработчиков
    0
    Осталось «прожить» эту длительную перспективу. Ибо при ограниченности денег любая «тратящая» перспектива внезапно становится не такой уж длительной…
  • RIM продаёт самолёт и инвестирует в BlackBerry-разработчиков
    +1
    ага, еще расскажите про «лучшесть» ОС владельцам премиум люмий и их перспективы апгрейда до следующей версии «лучшей из ОС»… только научитесь быстро бегать перед этим.
  • RIM продаёт самолёт и инвестирует в BlackBerry-разработчиков
    0
    Хмм, может в RIM не читали Мифический человеко-месяц или забыли закон Брукса?
    «Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.»


    А «сроки» у RIM явно существуют — «выйти и начать приносить прибыль пока не кончились деньги».
    И сроки уже поджимают, раз приходится так все распродавать.
  • Notepad++. Кириллические символы, ошибочно попавшие в код — решение проблемы
    0
    Сложноватый у вас Regex вышел, потому что вы работаете с символом\буквой как с окончательным объектом.

    А «символ» это всего лишь изображение, картинка для «слабых хьюманов» :). Изображение это задается числовым значением в таблице символов. Ничего не мешает поискать сами символы по диапазону их числовых значений, например вот таким регэкспом:

    [^\x00-\x7e]

    А шрифт — имхо странная идея. Вы комментарии на русском или другом языке читать не планируете?
  • Насколько крупны порносайты?
    +1
    Кстати вы будете смеяться но именно так — широкие каналы в интернет развиваются именно под давлением Content Delivery служб. Главный и самый траффикообразующий контент в интернете — совсем не минимизированные css+js и png картинки. High-res, fullhd и все такое.
  • Насколько крупны порносайты?
    +5
    Потом расскажете сколько людей добавило ваш комментарий в избранное ;)
  • Обновиться до Windows 8 можно будет с версии Release Preview за $39.99
    0
    Забавно будет узнать, что все это была шутка чтобы народ массово потестил Release Preview :)

    А если это правда — сейчас может резко вырасти спрос на легальные старые ОС. У меня где-то валялась коробка от лицензионной Vista, в свое время один из MVP подарил (для них цена в MS Store 15$ была). Итого если у вас есть знакомые MVP и вы хотите легализоваться на Win8 ( не уверен, что коробочная восьмерка будет сразу стоить 15$ для них) — просите купить Win7 недорого ;)
  • Отправляем письма из ASP .NET MVC
    0
    В общем речь больше о том — зачем «родине слонов» новые велосипеды :)
  • Отправляем письма из ASP .NET MVC
    0
    Эмм а простой System.Net.Mail.SmtpClient для отправки чем не угодил (http://msdn.microsoft.com/en-us/library/system.net.mail.smtpclient.aspx)?

    Варьируя DeliveryMethod — можете и на диск складывать и сразу отправлять
    Всякую асинхронность — берем, настраиваем стандартный smtp и кладем eml файлы в его папку Inetpub\mailroot\pickup. По сути — записали на диск=отправили ;)

    Хотите высшего пилотажа — Exchange Web Services имеет обертку на C#.
    А шаблонизаторы текста и генераторы формочек — пользуйтесь какими нравится
  • Билайн Wi-Fi бьёт адреса открытых до него вкладок
    +1
    хмм… Сколько пользуюсь бесплатный Wifi от билайна — ни разу такое не происходило. Обычно вкладок открыто больше 10-15. Когда нужна авторизация — открываю еще одну вкладку, произвольный мелкий сайт и через это обращение авторизуюсь. Единственная ситуация когда такое возникло — до авторизации нажал явно «обновить все вкладки» — ну тут уже ссзб.

    А можно вопрос — с какого фига ваш браузер на открытой и загруженной вкладке без причины сделал запрос в инет и перерисовал контент страницы? Некоторое странное поведение…

    PS У бесплатной Yota в этом плане все гораздо хуже. Билайн хоть адрес сохраняет, а йота редиректит на свой домашний сайт. И естественно теряет ссылку. Раньше такого не было. Видать им сильно надо посещения поднять — чтобы рассказать инвесторам что все хорошо…
  • Мы написали книгу! Практический опыт издания книги о программировании
    –1
    Кстати да, как вы честно оцениваете перспективы продаж книги, учитывая что скоро будет WP8, а апгрейда для владельцев WP7.5 устройств — не предвидится. Ну и имхо нет смысла начинать учить WP7.5 если платформа будет умирать\убита ( без маркета она будет очень быстро предана забвению).
  • Встречаем третий PowerShell (часть II)
    +2
    Клевые нововведения. На фоне всяких гуево-маркетинговых поделий, тут прямо чувствуется что при дизайне новых фич маркетинг слали лесом и делали полезные расширения.

    Хотя вот Workflow… в МС это походу «неприкаянный сын». Куда его только не приспосабливали — и раком и боком, все не нужен никому…
    Не удивлюсь если Rules в следующем MS Outlook предложат делать на Workflow :)
  • Последствия одного запрета или опять blackjack and hookers
    0
    Спасибо.
    Хмм, стоит сообщить более явно, что это можно отключать (и даже без регистрации ;) )
  • Последствия одного запрета или опять blackjack and hookers
    +1
    Посмотрим что получится… Только цензурируете мат как-то странно — во-первых количество букв теряется — догадаться что за слово написано — бывает трудно. Ну и фильтр подкрутите а то всякая глупость получается типа

    форума:
    ххх: Нужны 3х литровы@#$ки… 13 балонов заняла у соседки, надо теперь отдать. Может кто незнает куда их деть… могу забрать… Ребенок подрос пришла пора консерваций
    yyy: Аж мурашки по коже пробежали ;-)) Вы пускаете на консервы детей?
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    ;) Если говорить о дополнительных средствах типа подсказки от браузера — то тогда недалеко и до LastPass — автоввод регистрационных данных, генерация и запоминание паролей и все такое. Но это по сути сторонние фичи. в случае Raw — OpenID проигрывает OAuth по юзабилити. Даже мне не нравится вводить первую букву, т.к. серфинг все же идет при помощи мыши, а не клавы ;)
    Написание на стены и все такое — это необязательно надо пользовать, но комфортно и удобно получить дополнительные фичи за 1 проход…

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

    Протокол никак не меняет возможность сайта запросить максимум лишней инфы не пускать пока не получит.

    Oauth чаще всего сообщает базовую инфу о пользователе которая доступна публично (facebook) либо пользователь явно видит — сайт хочет получить доступ к email (google пишет).

    Также уже сейчас некоторые реализации OAuth позволяют подменять прям на лету важную инфу ( анонимный email в facebook или мультиаккаунт в Google). А для OpenId это вряд ли будут делать.

    Сайты без old-style регистрации — конечно же зло, а вот просто без OpenID — не вижу проблем. У нас только Old-style + Facebook + Google, и все довольно хорошо.

    А насчет заставлять регистрироваться на сайте соцсети — ну с 99% вероятностью (высосано из пальца, но фактически примерно так и есть) у всех моих знакомых есть аккаунт в соцсети, но что такое OpenId и как им правильно пользоваться — от силы знают 5%. А уж аккаунты в OpenId провайдерах (кроме ЖЖ, потому что это сначала соцсеть, а потом уже провайдер) — если у 3х людей найду — буду удивлен.

    А гемморой из статьи получать не нужно, надо читать спеки и реализовывать, там не сложно. А главное — всегда понимать, что именно ты делаешь в коде и для чего.

    Спасибо за приятное и пламенное общение ;)
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Этот комментарий — странный запутаный гон, написанный в пробке на мкаде.
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Кстати если обратите внимание, стандарты на протоколы часто не регламентируют употребление конкретной версии или способа защиты типа TLS 1.2 или такой-то алгоритм шифования. Просто говорят — имплементатор должен сделать надежно, на момент написания стандарта надежным считается технология X версии 1.2.3.7 и алгоритм шифрования Y, не менее 1024 бит. Как вы понимаете, после окончательного утверждения стандарта, правки в него не очень удобно вносить, а уж следить за изменяющимся ландшафтом надежности TLS или криптоалгоритмов — вообще не дело авторов. Поэтому конкретное применение HTTP|S в стандарте не обозначает что этот конкретный стандарт может работать только по http|s, в случае с OAuth 2.0 можно реализовать протокол хоть на голубиной почте ( если определенным образом голубей «защитить» от перехвата и подмены). Поэтому рекомендации о конкретной защите от Web-Based атак в протоколе общего типа — бессмысленны и даже вредны, так как запутывает реализатора.
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    ОКей… С точки зрения сферического коня — вы правы OpenId можно использовать для аутентификации и для регистрации. Вопрос — нужно ли?

    Есть несколько «неудобств» OpenId, с которыми «обычно» не соглашаются интерфейс-дизайнеры:

    1. Для аутентификации — надо ввести руками строку\урль, OAuth позволяет сделать то же самое действие одним кликом, или даже прозрачно на яваскрипте (см. StackOverflow например).

    2. Для регистрации — надо провалидировать email (если он нужен, а в сервисах он обычно нужен, домашние странички васи даже регистрации не должны требовать ;) ).
    Платформа предлагающая OAuth в этом случае «обычно» берет на себя проверку все того же пресловутого email (да да, кроме твиттера, которому даже переход на OAuth 2.0 не поможет), т.к. сервис-сайт все равно регистрируется для доступа к «платформе», то он может выбрать те, что предоставляют проверенные данные.

    Итак п.1 неудобен т.к. батхертит пользователей — надо вбить урл вместо клика на кнопке «войти»

    п.2 отвратитетелен тем, что сайт-сервис все равно должен проверить необходимые ему данные, это значит что для email нужно генерить линк, отправлять на почту, ждать захода по этому линку, после чего ставить галочку что да, пользователь наконец-то проверен и у него гарантированно правильный email.

    Про полезность писем — вопрос другой. В большинстве случаев если сервис спрашивает, значит считает что письма полезные ( и попробуй переубеди его ;) ), т.е. email чаще нужен, чем нет.

    Можно избежать п.2 и пускать только пользователей определенного набора провайдеров OpenID, которые сами требуют валидацию нужных вам данных.
    Это, во-первых, приводит к ситуации, когда приходят в саппорт юзеры и начинают ныть — «А почему вы пускаете OpenA и не пускаете OpenB, это дискриминация» или «А почему вы не пускаете всех подряд, вот у меня дома на роутере стоит свой OpenId провайдер, я хочу чтобы ваш сервис верил тому, что он „рассказывает“.
    Во-вторых — сводит удобство OpenID, как универсального и провайдеро-независимого решения, на нет. т.к. появляется зависимость от провайдера.

    В чем преимущество OAuth — есть удобство общего назначения, в виде доступа к API конкретной платформы: получить данные о пользователе, на стене написать, календарик попросить и что-нить полезное показать, подсказать друзей которые уже на сервисе и все такое.

    Есть частное удобство для пользователя — он чаще уже залогинен в сервис платформы (ибо он часто пользуется соцсетью, куда чаще чем своим „провайдером“, которые часто ничего кроме „провайдера OpenId“ и не предоставляют). И в этом случае — ему надо сделать максимум 2 клика ( кнопка войти и кнопка разрешить доступ приложению) чтобы оказаться на сайте. А в идеале (повторный заход) — вообще в один клик. И все, остальное делают сервисы, автоматически, ну 1-2 редиректа в фоне пролетят, юзер и не заметит.

    И вот именно этот сценарий, который удобен как юзеру, так и сайту (заботящемуся о легком входе к себе, но требующему некоторой проверенной информации для работы) побеждает.

    А OpenId c его идеологией и свистоплясками слишком неудобен для всех сторон:
    1. Юзеру надо вводить урль ( что обычно длинее логина, а если вводить логин — надо выбрать правильного своего провайдера).
    2. Сервису надо в любом случае проверить данные о пользователе от провайдера, или довериться конкретному провайдеру (что приведет к ограничениям описанным ранее и аннулирует преимущества OpenId)

    Ну и кому, кроме убежденных гиков, нужна эта „морская свинка“ от мира аутентификации и регистрации под названием OpenID 2.0?

    Юзерам лень что-то делать, а сервисы хотят переложить не нужную им работу на других (валидация данных).

    Все, силы разума в очередной раз победили вселенское сферическое добро.
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    идея openId именно в том, что сайт доверяет ЛЮБОМУ провайдеру, а не фиксированному набору, т.к. «любой провайдер» может быть вашим приватным и стоять на вашем сервере. Цель — единое место хранения ваших данных, чтобы сервера не хранили у себя их отдельно, а обновляли на основе ответа от некоего централизованного сервера ( вашего провайдера). чтобы вы могли свое имя поменять в провайдере и все сайты вас переименовали.
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Да не в капче дело, и не в лени. Я пытаюсь сказать, что openId — это только способ быстрой РЕГИСТРАЦИИ, после которой надо еще отдельно аутентифицировать пользователя.
    Максимум, что можно использовать для секрета аутентификации — это сам url, владение которым пользователь заявил. А вот делать на основе этого «владения» предположения, что он владеет и email, который был возвращен провайдером — нельзя, email надо проверять отдельно ( или использовать только тех провайдеров, которые делают эту проверку за вас, т.е. ограниченный список)

    Пустить на сайт означает аутентифицировать, а не зарегистрировать. Я могу зарегать аккаунт на ваш email, но без доступа к вашему ящику, я не смогу провалидировать мое «заявление» о том «я — владелец ящика». Эта проверка нужна для определенных сценариев

    А OAuth в текущем виде и в сценарии его общепринятого «нетрадиционного использования» сможет именно подтвердить АУТЕНТИФИКАЦИЮ пользователя.

    В этом вся разница, которую я хотел донести.
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Да, торопился ( выезжал на работу) и невнимательно выразился. Вы правы, OpenId действительно про доказательство контроля конкретного url, и «логин» там может только улучшить юзабилити, все равно будет сформирован ожидаемый урл. Все так.

    И там далее, насколько помню, есть механизм, чтобы получить данные, которые ввел владелец урла, чтобы быстрее зарегистрировать владельца на сайте.

    Но вот OpenId протокол не подтверждает, что пользователь, владеющий урлом, действительно владеет теми данными, которые он ввел. И создавать на основе этого аккаунт без проверки «владения» заявленным email не обойтись. Это необходимо в «общем» случае.

    Если использовать только проверенные сервера-провайдеры openId (частный случай), которые сами требуют валидации email, тогда все ок.
    Но такой подход противоречит самой идее OpenID — когда ты можешь войти на сайт, используя любой, даже собственный OpenId провайдер на домашнем сервере
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Давайте попробуем кратко и по существу ;)
    1. Вы утверждаете что уязвим протокол OAuth 2.0 или уязвима конкретная либа, его реализующая, omniauth?
    1.1 Если либа — вопросов нет, криворуких программистов на свете много и их либы — довольно жалкие поделия.
    1.2 Если говорите что сама концепция ( а «протокол» это порядок действий и соглашение о форматах) OAuth 2.0, то будьте любезны просмотреть драфт протокола и сказать какое именно место протокола уязвимо.

    Это 2 очень принципиальных поинта — уязвимость реализации и уязвимость всей идеи. Хочется точно понять, что именно вы утверждаете.

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

    2. Поясните что же именно скрывается под мастер аккаунтом, потому как я не понимаю, из видео — это какой-то аккаунт на сайте, не более того.

    3. Если вы настаиваете что идея уязвима, а не либа, предложу в PM способ проверить уязвимость идеи на примере конкретного сайта, в котором есть Login With Facebook и где не составит проблем понять, действительно ли проблема в протоколе или проблема в реализации. Я, юзер, перейду по сформированной вами ссылке-редиректу на этот сайт с токеном FB. Открою честно, в In-Private режиме Google Chrome, чтобы не было шансов того, что я залогинен. После этого если вы скажете содержимое моей текущей истории на сайте (а вы предполагаете что потом вы сможете зайти со своим ФБ в мой мастер? аккаунт, правильно же), мы обнародуем результаты и наверное прославимся, т.к. найдем фундаментальную уязвимость в протоколе OAuth 2.0.

    Устраивает?
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Ну привет, Егор ;).
    Жаль что не ознакомились, я вот ваше видео в итоге раза 4 пересмотрел, чтобы понять суть описываемой проблемы.

    Да, пока я действительно не понял что такое мастер аккаунт в ваших терминах.
    Мастер это акк на сайте Х, в который вы можете войти через ФБ ( т.е. есть у сайта связка «ФБ-что-то»-> Аккаунт1-на-сайте? )

    Если почитать OAuth, то за исключением удобства http\TLS — там вообще нет привязки к протоколу передачи данных. Можно взять и реализовать это на TCP\IP. Сурово но можно. Сам OAuth описывает порядок взаимодействия сторон,3-legged-oauth, а не то, как надо использовать http. Просто для удобства он полагается на http|s — так приводить примеры проще, иначе общая теория выносит мозг
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    неа, для того чтобы вы могли отличать одного пользователя от другого — вам не нужна регистрация. Можно тупо взять юзерагента+ плагины с версиями и получится очень уникальная строка. Где-то в юса-вузе это уже показали на практике.

    Регистрация это способ предоставить пользователю, и только ему, персонализированное взаимодействие с сайтом. например хранение документов пользователя в гугль докс. Для этого нужен некий «разделяемый секрет», который знает пользователь и который может проверить сайт (эээ пароль ;) и хэш пароля у сайта в простейшем случае).

    Если приложение не хочет или не может хранить инфу для проверяемого секрета, оно может перевалить эту обязанность другому сайту ( это некоторая вольная интерпретация). Например если наш сайт Х доверяет тому, как гугл хранит и защищает пароли пользователей, то мы, делая вход через гугл, декларируем следующее: «Я доверяю гуглу, поэтому я не буду сам проверять ваш пароль, а пусть гугл проверит ваш пароль на нем, а мне скажет ваш логин. Вот как он скжет, так я вас и залогиню». Все, вы можете не хранить хэши паролей вообще, а просто собрать набор сайтов, которым вы доверяете и жить на этом «доверии».

    Если один из таких доверенных сайтов фэйлит — у вас проблемы, т.к. в чужой акк на вашем сервере можно зайти обманув доверенный сервер.

    OpenId изначально не предполагает такой уровень доверия, OpenId говорит как бы — «Сайт, вот тебе строка моего логина на сайте, по стандартному протоколу ты можешь получить обо мне всю информацию что я завел».
    Но это никак не подтвердит что вы — именно тот человек, который это заводил. Поэтому для быстрой регистрации опенид — допустим, а вот для дальнейшего регулярного входа на сайт — должно быть то же самое «доверие» к провайдеру. А провайдер может поручиться только за записи, которые явно с ним связаны, поэтому сайт должен держать связь логин+провайдер, что на самом деле ружит идею опенид почти полностью, потому как предполагалось что сайты будут доверять ЛЮБОМУ опенид провайдеру.

    А все-таки насчет масс регистрации — одно дело когда сайт — это форум, ну пришли боты, потроллили и все такое. А другое дело — когда это некий сервис предоставляющий демо-услугу, а за больший объем хотящий денег. Вто там массовая регистрация позволит получить услугу в большем объеме (маленькими демо-кусочками) и возможно нанесет финансовый ущерб сайту.

    Все в итоге зависит от того, что именно вы предоставляете и насколько важна для вас регистрация.
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    в п.3 читать «сайт передает а-токен»

    … Интересно, этот коммент кто-нибудь осилит и осмыслит полностью при первом прочтении ;)?
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Лично я — не смешиваю, я их очень хорошо отличаю.

    OpenId — это быстрая регистрация. Проблема «быстрой регистрации» в том, что ее очень любят боты.

    OAuth 1.0 и 2.0 — это способ авторизации стороннего приложения для доступа к ресурсам от имени пользователя. Для аутентификации это используется так, что спрашивается емейл пользователя и этому ответу доверяем.

    Касательно «кликнуть по ссылке» — это не так, пользователи обычно ленивы и не ходят в почту, кривая почта может попасть в спам или вообще быть убитой на сервере, не дойдя до ящика пользователя. Все это не увеличивает количество пользователей с проверенными email.

    В случае с доверием ЛЮБОМУ OpenID провайдеру (доверять 1-2-3 и не доверять другим — работает, но выглядит дико) — есть простая проблема. Я напишу свой openId сервер таким образом, что он будет ВСЕГДА генерить рэндомные комбинации юзернейма, email на моем домене ( или на mailinator.com) и будет сам активировать присланные письма. И добро пожаловать в мир миллиона халявно зарегистрированных аккаунтов на вашем сервере.

    Если же мы доверяем «только нескольким» серверам Oauth\OpenID — то мы предполагаем что там и email уже валидный, можно самому не валидировать (если там не валидный- это значит большие проблемы), и что сами сервисы умеют хорошо защищаться от массовой регистрации аккаунтов у них самих, ну хотя бы получше чем вы сами.

    Но даже в этом случае (это касательно «удобного логина») никто не защитит вас от сценария, когда вы зареганы на OpenID-Provider-1 и желаемый login у вас user1 а почта user1@gmail.com, а я зареган на OpenID-Provider-2, а вот никнейм (суть логин) я вписал тоже user1. А еще если мой провайдер кривой и НЕ проверяет почту на владение (т.е. при вводе почты вам нужно перейти по ссылке ) или я как-то смог подтвердить почту user1@gmail.com, то я легко зайду под вашим аккунтом в сайт, который доверяет обоим провайдерам.

    Поэтому мечты об удобном предпочитаемом логине user1, а не user1.OpenId-Provider-1 идут далеко и надолго. Это вроде очевидно.

    В остальном же про капчу\емейл и т.д, в общем возражений нету и я говорил примерно то же самое что и вы. Для меня OAuth технически удобней OpenID, даже если он используется не по назначению.

    А так — почта, только почта может честно, уникально и удобно идентифицировать юзера ;)
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Уговорили… Про «ленивых в Security» часто рассказывают в новостях о про… теряных хэшах без соли и на инструктажах по технике безопасности ;)
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Почитайте мой коммент ниже, такая привязка не проблема протокола…
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    100% совпадение валидно, тут я прогнал немного, извиняюсь.
    просто оно блин сильно неудобно…
  • OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
    0
    Мну интересует что же вы подразумеваете под «вышеописанного недостаточно для надежной и безопасной авторизации», ибо пока что я не согласен, а слушать «критиков OAuth» — ну так 3.14здеть это не мешки ворочать. А вот о «проблемах по существу» еще ни разу не слышал, все как-то соскальзывают или оказывается проблема не в OAuth 2.0.

    Удобство — да, не всегда еще удобно, стандарта-то финального нет, только черновики. А вот сомнения в надежности — очень любопытно послушать