Comments 40
Да ни один нормальный магазин в жизни не поставит себе его, только потому, что платежи хотя бы для обычных кредитных карт принимать то надо.
Сегодняшняя идеология OpenID уязвима в целом. Многие не доверяют OpenID провайдерам — и это верно. Неизвестно, что станет с таким провайдером в будущем. И даже Гуглу в этом плане доверять не стоит. А уж контакту — тем более. Я не параноик, но потерять доступ к аккаунту на форуме, где я активно общался — неприятно. Да и «не стоит класть все яйца в одну корзину».
Идеологию авторизации на сайтах уже давно пора привести к идеологии вроде авторизации ssh по ключам. При регистрации заливаем на сайт открытый ключ — он содержит в себе необходимую информацию для регистрации — ник, дату рождения, почту и т.д, указывая — заполнять только обязательные параметры для регистрации или все подряд. Ничего ручками вбивать не нужно — просто залили файлик и сайт получил необходимую информацию. А авторизоваться уже по закрытому ключу, который можно хранить на внешнем носителе (привет ssh по usb флешке), подключать сертификатом в браузере (привет компы, используемые одним человеком) или просто подключать через утилиту с мастер паролем.
Да, понятно, что нужно придумать механизм по восстановлению закрытого ключа (утилита, генерирующая закрытый ключ из открытого с использованием адски сложного мастер пароля, который указывается при первом создании закрытого ключа?). Либо совершенствовать OpenID — например, мультиаккаунтинг. То есть, чтобы на сайтах можно было авторизовываться в один аккаунт из нескольких OpenID — например, с личного сервера, с Google Apps (если появится), с самого гугла. Ну и с яндекса и прочих. В таком случае шанс потерять аккаунты — снижается.
Идеологию авторизации на сайтах уже давно пора привести к идеологии вроде авторизации ssh по ключам. При регистрации заливаем на сайт открытый ключ — он содержит в себе необходимую информацию для регистрации — ник, дату рождения, почту и т.д, указывая — заполнять только обязательные параметры для регистрации или все подряд. Ничего ручками вбивать не нужно — просто залили файлик и сайт получил необходимую информацию. А авторизоваться уже по закрытому ключу, который можно хранить на внешнем носителе (привет ssh по usb флешке), подключать сертификатом в браузере (привет компы, используемые одним человеком) или просто подключать через утилиту с мастер паролем.
Да, понятно, что нужно придумать механизм по восстановлению закрытого ключа (утилита, генерирующая закрытый ключ из открытого с использованием адски сложного мастер пароля, который указывается при первом создании закрытого ключа?). Либо совершенствовать OpenID — например, мультиаккаунтинг. То есть, чтобы на сайтах можно было авторизовываться в один аккаунт из нескольких OpenID — например, с личного сервера, с Google Apps (если появится), с самого гугла. Ну и с яндекса и прочих. В таком случае шанс потерять аккаунты — снижается.
Почему-то не доверяют провайдерам OpenID, но доверяют хостерам эл. почты и регистрируются через эл. почту. А она уязвима ровно в той же мере, что и OpenID — ровно та же зависимость от провайдера и ровно те же вопросы. Просто замените «OpenID» на «email» в своем комментарии, он останется правильным.
Мультиаккаунтингу технология OpenID не препятствует, и это реализовано на многих сайтах. Ничто также не мешает совмещать OpenID с эл. почтой и тд., просто как альтернативные варианты входа в один и тот же аккаунт. Зависимость от провайдера OpenID устраняется просто: 2 строки html на личной странице (я бы сказал, что это проще, чем свой почтовый сервер поднимать).
В итоге оказывается, что между OpenID и email больше общего, чем между OpenID и Open API.
Мультиаккаунтингу технология OpenID не препятствует, и это реализовано на многих сайтах. Ничто также не мешает совмещать OpenID с эл. почтой и тд., просто как альтернативные варианты входа в один и тот же аккаунт. Зависимость от провайдера OpenID устраняется просто: 2 строки html на личной странице (я бы сказал, что это проще, чем свой почтовый сервер поднимать).
В итоге оказывается, что между OpenID и email больше общего, чем между OpenID и Open API.
Совсем потерять почту на своём домене (особенно, если домен используется только для почты) несколько менее вероятно, чем потерять OpenID аккаунт.
Проблему угона аккаунтов OpenID, кстати, тоже не решает. Даже наоборот — усугубляет. С почтой же ты не потеряешь автоматически все аккаунты, а только те, про которые знает злоумышленник. Ну и те, на которых почту сменить нельзя.
Проблему угона аккаунтов OpenID, кстати, тоже не решает. Даже наоборот — усугубляет. С почтой же ты не потеряешь автоматически все аккаунты, а только те, про которые знает злоумышленник. Ну и те, на которых почту сменить нельзя.
Иметь OpenID аккаунт на своем домене — это 2 строки html-кода, это проще, чем иметь почту на своем домене.
UFO just landed and posted this here
Нет, не понадобится. Есть такая штука — делегирование. Вот, например, как можно яндексовый openid к своему домену подключить: openid.yandex.ru/info/delegation/.
На stackoverflow.com можно привязать 2 openid к аккаунту.
У меня привязан openid, который висит на моём блоге и openid гугла.
У меня привязан openid, который висит на моём блоге и openid гугла.
UFO just landed and posted this here
Никто меня не понимает, пойду в угол плакать) Именно что: это правило выгодно контакту, это правило не применимо к OpenID, а применимо только к приложениям, поэтому контакт сделает все, чтобы не стать провайдером OpenID — прямо или косвенно. Чтобы не предоставлять альтернативу: применять или не применять это правило. Они там не дураки делать самим себе хуже, поэтому OpenID и не будет — ни прямо, ни косвенно.
Да чем же оно выгодно контакту? Контакт регулирует оплату услуг в приложении, а не на сайте. А приложение используется только для идентификации пользователя, никаких услуг оно не предоставляет. Не вижу здесь большей выгоды, чем от использования OpenID, хоть убей.
Во-первых, регистрируемое приложение имеет тип «веб-сайт». А во-вторых, там в правилах приписка есть: «в том числе на сторонних сайтах». Я ее могу никак иначе понять не могу, кроме как запрещение использовать другие платежные системы на сайте, где подключено что-то из Vkontakte API (например, вход).
Если выйдут представители ВКонтакте и скажут: «это все не так, официально заявляем, все можно использовать» или вообще уберут приписку эту — буду рад, что оказался не прав.
Если выйдут представители ВКонтакте и скажут: «это все не так, официально заявляем, все можно использовать» или вообще уберут приписку эту — буду рад, что оказался не прав.
Это правило относится к приложениям вроде «Счастливый фермер», чтобы они не использовали Webmoney или собственный SMS сервис для получения «плюшек» минуя контакт. В этом есть смысл — контакт предоставляет площадку для приложения, и клиентов, и он хочет за это денюжку.
Заставлять использовать только контактовскую платежную систему в, например, интернет-магазине никто не станет, это как минимум глупо, и просто не даст системе авторизации OpenAPI распространиться на крупных сервисах, что в свою очередь поставит под удар монополию контакта на российских пользователей.
Заставлять использовать только контактовскую платежную систему в, например, интернет-магазине никто не станет, это как минимум глупо, и просто не даст системе авторизации OpenAPI распространиться на крупных сервисах, что в свою очередь поставит под удар монополию контакта на российских пользователей.
Мы тут ходим по кругу, который можно разорвать, только приведя цитату из официального источника, которая бы подтверждала, что «это правило относится к приложениям вроде «Счастливый фермер»» и не относится к веб-сайтам, использующим Open API.
Пока я вижу только правила, где черным по белому написано, что оплату нельзя принимать не только на flash-vkontakte-приложениях, но и на сторонних веб-сайтах, которые как-то используют Open API.
Конечно, тут можно ошибиться, и прояснить ситуацию могут только оф. источники. Спорить о трактовках нам смысла мало. Смысл есть подумать, как данная ситуация влияет на наши действия:
1. Трактую правила неправильно. Из-за этого прикручу вход через контакт позже, только когда все прояснится. Это затормозит развитие, но это и не катастрофа, как жили без OpenAPI, так и проживем.
2. Трактую правила правильно. Но все же прикручиваю вход через вконтакте сейчас. Потом приложение прикрывают, клиенты не могут зайти в свои аккаунты и начинают греть паяльники для владельцев сайта.
3. Утопично и самонадеянно: трактую правила правильно. Вконтакте видит бурление народных масс и говорит, что на самом деле все можно, и, возможно, даже убирает пункт.
Пока я вижу только правила, где черным по белому написано, что оплату нельзя принимать не только на flash-vkontakte-приложениях, но и на сторонних веб-сайтах, которые как-то используют Open API.
Конечно, тут можно ошибиться, и прояснить ситуацию могут только оф. источники. Спорить о трактовках нам смысла мало. Смысл есть подумать, как данная ситуация влияет на наши действия:
1. Трактую правила неправильно. Из-за этого прикручу вход через контакт позже, только когда все прояснится. Это затормозит развитие, но это и не катастрофа, как жили без OpenAPI, так и проживем.
2. Трактую правила правильно. Но все же прикручиваю вход через вконтакте сейчас. Потом приложение прикрывают, клиенты не могут зайти в свои аккаунты и начинают греть паяльники для владельцев сайта.
3. Утопично и самонадеянно: трактую правила правильно. Вконтакте видит бурление народных масс и говорит, что на самом деле все можно, и, возможно, даже убирает пункт.
Попробую прояснить мою мысль.
Правила эти создавались до появления OpenAPI, и возможно, не редактировались после. В моем понимании, под «в том числе на сторонних сайтах» подразумевается, что нельзя продавать внутриигровую валюту в обход контакта, в том числе не только в приложении, но и на внешнем сайте приложения, или используя торговые площадки.
А неразбериха в правилах вызвана тем, что «В Контакте», пытаясь объединить все свои API, просто смешал мягкое с теплым — приложения и авторизацию.
Имхо.
Правила эти создавались до появления OpenAPI, и возможно, не редактировались после. В моем понимании, под «в том числе на сторонних сайтах» подразумевается, что нельзя продавать внутриигровую валюту в обход контакта, в том числе не только в приложении, но и на внешнем сайте приложения, или используя торговые площадки.
А неразбериха в правилах вызвана тем, что «В Контакте», пытаясь объединить все свои API, просто смешал мягкое с теплым — приложения и авторизацию.
Имхо.
Я категорически не согласен. Во-первых из цитаты пользовательского соглашения не совсем понятно что именно ограничивается, весь сайт или только приложение? Там написано про приложение, то есть если Вы используете OpenAPI для продажи какой то услуги связаной с вконтакте (например продаёте подарки друзьям юзера) то можете платить только через деньги вконтакте, но если вы продаёте хлеб и при продаже OpenApi никак не задействован — нет никакого нарушения.
Во-вторых OpenAPI сделан для работы с данными юзера, а не для аутентификации. Это свойство не может предоставить OpenID. На данный момент для этого существует OAuth ну и может ещё какие то гибриды OpenID с OAuth о которых иногда пробегает информация в интеренете.
То что они хотят захватить рынок виртуальной валюты это конечно не вызывает сомнений, а кто не хочет? Но OpenAPI я думаю здесь не причём :)
Во-вторых OpenAPI сделан для работы с данными юзера, а не для аутентификации. Это свойство не может предоставить OpenID. На данный момент для этого существует OAuth ну и может ещё какие то гибриды OpenID с OAuth о которых иногда пробегает информация в интеренете.
То что они хотят захватить рынок виртуальной валюты это конечно не вызывает сомнений, а кто не хочет? Но OpenAPI я думаю здесь не причём :)
OpenID имелось ввиду в последнем предложении.
UFO just landed and posted this here
то есть если Вы используете OpenAPI для продажи какой то услуги связаной с вконтакте (например продаёте подарки друзьям юзера) то можете платить только через деньги вконтакте, но если вы продаёте хлеб и при продаже OpenApi никак не задействован — нет никакого нарушения.
Понимаете, запрет на использование сайтом (сторонним сайтом, не самим приложением!) других платежных систем там прописан явно, а то, что это применимо только к вконтактным подаркам друзьям и тд — это не написано нигде (ведь так?) и это просто наши домыслы.
Здорово будет, если я окажусь не прав. Или уберут этот пункт. Но пока — надеяться на авось, наверное, неправильно.
А как же vkontakteid.ru/?
какой нормальный человек/магазин будет принимать платежи через вк, если они себе забирают минимум 70% от платежа с пользователя?
а по-моему Merchant API (для интернет-магазинов) и ВКонтакте API (для приложений)
это разные вещи.
если вы создаете приложение (а к нему можете и сайт подвязать), то вы не можете принимать другие методы оплаты.
а если вы подключаете магазин, то можете принимтаь оплату другими методами.
правил и лицензионного соглашения для Merchant API так и не нашел.
это разные вещи.
если вы создаете приложение (а к нему можете и сайт подвязать), то вы не можете принимать другие методы оплаты.
а если вы подключаете магазин, то можете принимтаь оплату другими методами.
правил и лицензионного соглашения для Merchant API так и не нашел.
Примеры по настоящему крупных магазинов, завязавшихся на авторизацию ВКонтакте, можно?
Я лично вообще не понимаю кому это может понадобиться — ведь есть lj
Мне кажется, автор сильно ошибается. В приведенной цитате речь идет именно о приложениях, размещенных внутри социальной сети. OpenAPI к этому отношения не имеет. То, что для его работы требуется завести пустое приложение — заглушку — это всего лишь костыль, я подозреваю. После авторизации на сайте, приложение в дальнейшей работе не участвует, а залогиненный юзер продолжает пользоваться вашим веб-ресурсом, не имеющим никакого отношения к контакту.
Не надо строить теории заговора, как следует не разобравшись в предмете. Короче, в тред призываются официальные представители Павла Дурова :)
Не надо строить теории заговора, как следует не разобравшись в предмете. Короче, в тред призываются официальные представители Павла Дурова :)
Насчет официальных представителей поддерживаю) Но во-первых, речь идет не о приложениях, размещенных внутри соц. сети, т.к. выбирается тип приложения «веб-сайт» (а не «Flash-приложение», например). Т.е. тут приложение — это и есть веб-сайт. А во-вторых, там явно написано: «Принимать оплату услуг в приложении отличными от внутренней валюты ВКонтакте способами, в том числе на сторонних сайтах».
Хорошо, если сильно ошибаюсь)
Хорошо, если сильно ошибаюсь)
OpenID имеет ключевую непобедимую уязвимость: пользователям преждлагается вводить свои логины/пароли на чужих сайтах. Более того, нет в браузере нет никаких средств защиты от фейковых сайтов для сбора паролей. Чем занимаются люди в W3C?
UFO just landed and posted this here
Во-первых, сейчас придумывают всякие штуки с открытием формы ввода пароля/логина через ифреймы и яваскрипты. Во-вторых, для пользователя форма ввода логина и форма ввода логина с паролем идеологически не раздичаются. В-третьих, часть пользователей пугают «не воодить свои логины и пароли на других сайтах». В-четвертых, очень трудно отличить фейк от настоящего сайта (какого-нибудь vontakte.ro), и неет никакой системы защиты от фейков.
А виноват кто? W3C — что не придумывает никакой защиты, и разработчики − что используют небезопасные способы авторизации пользвоателя.
А виноват кто? W3C — что не придумывает никакой защиты, и разработчики − что используют небезопасные способы авторизации пользвоателя.
Автор не разбирается в предмете
Ну что можно сказать, есть аргументы — пишите.
vkontakteid.ru/ — следующая ваша заметка будет называться «Почему ВКонтакте стал провайдером OpenId»? :)
времена изменились и пункт тоже
Принимать оплату виртуальных товаров и услуг в приложении отличными от внутренней валюты ВКонтакте способами, в том числе на сторонних сайтах
т.е. магазинам ура ура можно принимать любую валюту за реальные товары.
Принимать оплату виртуальных товаров и услуг в приложении отличными от внутренней валюты ВКонтакте способами, в том числе на сторонних сайтах
т.е. магазинам ура ура можно принимать любую валюту за реальные товары.
Sign up to leave a comment.
Почему ВКонтакте не станет провайдером OpenID