Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 208
Вы еще API Одноклассников не видели. Например, через него просто невозможно опубликовать новость в группе.
Не должны. Я не хочу, чтобы админы сайта, на котором я авторизуюсь через ВК, читали мою переписку.
Одновременно с тем же я не понимаю, почему нет авторизации по паре логин+пароль. Вместо этого я должен использовать б-гомерзкий Web-компонент, засоряющий моё приложение. Для Symbian это вообще беда.
Одновременно с тем же я не понимаю, почему нет авторизации по паре логин+пароль. Вместо этого я должен использовать б-гомерзкий Web-компонент, засоряющий моё приложение. Для Symbian это вообще беда.
Не очень понял. Причем тут авторизация на сайтах? При простой авторизации сайт получит только доступ к общей и публичной информации: как вас зовут, как выглядит ваш аватар и так далее. Для получения доступа к сообщениям и прочему, приложение должно специально запросить соответствующее разрешение, а вы — подтвердить.
В таком случае должны быть галочки, которых нет.
Я, например, хочу, чтобы сайт/приложение читало мою стену, но не трогало аудио.
А если приложение просит и того и того, отказаться от одного из пунктов, оставив другой, нельзя.
И, да, я говорю о внешних приложениях. Во внутренних ВК так делать, вроде, можно.
Я, например, хочу, чтобы сайт/приложение читало мою стену, но не трогало аудио.
А если приложение просит и того и того, отказаться от одного из пунктов, оставив другой, нельзя.
И, да, я говорю о внешних приложениях. Во внутренних ВК так делать, вроде, можно.
Я придерживаюсь при создании такого рода приложений простого правила: запрашивать только те возможности, которые действительно необходимы для нормальной работы. Если форум попросит у меня доступ к чтению личных сообщений, то это косяк разработчика этого форума. Я зайду на него иным способом или просто не буду пользоваться.
С учетом вашего протеста против предоставления прав сторонним приложениям, немного странно выглядит вопрос: «Почему нет авторизации по паре логин + пароль»? Временный доступ через токен к ограниченному набору данных я готов выдать, а вот подарить приложению логин и пароль — увольте. Суть OAuth как раз и заключается в том, что доступ к паре логин/пароль имел только провайдер (в данном случае — ВК), но не потребитель.
С учетом вашего протеста против предоставления прав сторонним приложениям, немного странно выглядит вопрос: «Почему нет авторизации по паре логин + пароль»? Временный доступ через токен к ограниченному набору данных я готов выдать, а вот подарить приложению логин и пароль — увольте. Суть OAuth как раз и заключается в том, что доступ к паре логин/пароль имел только провайдер (в данном случае — ВК), но не потребитель.
Авторизация по паре логин-пароль есть (ну или, во всяком случае, была).
В этом посте упомянут вот этот пост про vk fuse: habrahabr.ru/post/85014.
Так вот, автор этого vk use успешно авторизуется по паре логин-пароль простым запросом (см. код).
Но при этом в документации vk api я такого способа не находил.
Может быть, это потому что этот способ считается устаревшим.
А может быть, потому что его уже отключили.
В этом посте упомянут вот этот пост про vk fuse: habrahabr.ru/post/85014.
Так вот, автор этого vk use успешно авторизуется по паре логин-пароль простым запросом (см. код).
Но при этом в документации vk api я такого способа не находил.
Может быть, это потому что этот способ считается устаревшим.
А может быть, потому что его уже отключили.
Хм… Мне всегда хватало документации. Однотипные вызовы через HTTP. После переработки сайта для разработчиков, там появилась еще и возможность дернуть метод напрямую из веб-интерфейса прямо на vk.com/dev. Это еще больше все упростило.
А как пользователю определить, будете ли вы отправлять спам-сообщения всем подряд, или будете делать именно то, что заявляете? Вы же можете сделать серверную авторизацию по паре логин-пароль, и всё прекрасно будет работать(это хак, а не их фишка), только вот далеко не все пользователи согласятся вводить вам на сайт свой пароль. Тут вопрос скорей в том, что они не хотят разгребать тонны жалоб от пользователей приложений злоумышленников.
P.S. Если кому интересно, могу скинуть простенькую реализацию интерфейса vk
P.S. Если кому интересно, могу скинуть простенькую реализацию интерфейса vk
Да, это вопрос доверия к приложению. Но решать должен прежде всего пользователь. Не думаю, что это оправданно — снимать с него ответственность через запрет. Ведь в, скажем, Android SDK вам никто не запрещает запросить доступ к SMS? Дать или нет — вопрос к пользователю. Из-за боязни убийства при помощи вилки, уничтожается под корень целый класс приложений, которые бы могли здорово расширить возможности ВКонтакте.
Важный момент: первые несколько месяцев приложение может быть реально полезным, чтобы набрать популярность, а потом начать пользоваться своей «властью». С тем же Android'ом так произойти не может, хотя в этом я точно не уверен.
Такие случаи возможны, вы правы. За них нужно очень и очень строго карать. С этим тоже не спорю. Однако, повторюсь, это, с моей точки зрения, не оправдывает тот факт, что просто не существует легальной возможности создать нормальное, честное и полезное приложение с расширенными возможностями. Отсюда хаки с серверной авторизацией.
ну как бы — другие сайты и соц. сетки все-таки по-умолчанию разрешают это. и ничего, пока живы
Ну да, согласен, но у VK на это свои причины, которые, в том числе, касаются спама и жалоб. Хотя, кстати, посылать одно и то же сообщение не получится, то-есть вопрос со спамом они решили.
рандом спасет спамеров :)
в упор не понимаю, какие могут быть такие причины у ВК, которых нет в FB и Twi
Разница в законодательстве и/или менталитете ЦА.
Я бы понял, если бы все было наоборот, ведь законодательство о работе с такого рода данными в Европе/Штатах, думаю, куда жестче. Да и вероятность в суд уйти выше. Но в данном случае как раз ВК не дает делать того, что позволяет FB =)
Вы так говорите, будто при авторизации пользователи читают на что они соглашаются. Даже 20% нечитающих пользователей хватит, чтобы они вдруг стали злостными спамерами, и об этом узнало всё vk.
...(ошибся веткой комментов)...
Мне больше не нравится это: vk.com/bugs?act=show&id=49112799_1
Я дважды писал в поддержку, на что мне отвечали, что передали это разработчикам, я завел тикет, но никакой, совершенно никакой, реакции со стороны программистов VK. Это при том, что лично Дуров говорил, что они следят за проектом Meridian.
Я дважды писал в поддержку, на что мне отвечали, что передали это разработчикам, я завел тикет, но никакой, совершенно никакой, реакции со стороны программистов VK. Это при том, что лично Дуров говорил, что они следят за проектом Meridian.
Я писал ребятам как-то по поводу бага с newsfeed.search. Ответили быстро, обещали исправить. Сейчас он из трекера исчез. Исправили или нет — не проверял.
Хотя отчасти я с вами соглашусь. Прозрачности в работе над VK API очень и очень не хватает. Что собираются делать? Что менять? Куда присылать предложения и описания проблем? Как разработчик API знаю, что это очень важно для сервиса — хороший и плотный контакт с сообществом сторонних разработчиков. У ВК этого нет. Поэтому пост на Хабре, а не личная переписка с ними.
Хотя отчасти я с вами соглашусь. Прозрачности в работе над VK API очень и очень не хватает. Что собираются делать? Что менять? Куда присылать предложения и описания проблем? Как разработчик API знаю, что это очень важно для сервиса — хороший и плотный контакт с сообществом сторонних разработчиков. У ВК этого нет. Поэтому пост на Хабре, а не личная переписка с ними.
«А нельзя ли как-то все таки получить токен с нужными привелегиями, если я честный парень и клятвенно обещаю не рассылать спам, не создавать ботов и молиться правильным богам?»
А Вы можете указать хотя бы один способ достоверного определения честности в интернете?
Достоверного способа определить честность в Сети нет. Зато есть репутация, кредит доверия. Вы правда думаете, что искусственное ограничение — лучший способ контроля? Если я или вы очень захотим написать спамбота для ВК, мы это сделаем, не так ли? Выше предлагались способы. Но зачем отнимать право легального написания нормального софта? К чему толкать меня на хаки? Заранее виновен? =)
Сомневаюсь, что проблема кроется в «виновен — не виновен», ставить так вопрос глупо, т.к. помимо репутации программиста есть еще и репутация vk, на которую будут влиять все изменения в репутации разработчика, тем более негативные.
Я так и не понял, за что меня лишили права делать хорошие вещи нормально, подтолкнув к разного рода хакам?
Просил разработчиков сделать реал-тайм подгрузку новостей в виджете сообществ (предварительно проштудировав документацию по API и убедившись, что такая функция есть, только для другого функционала). Разработчики ответили, что не готовы реализовать такую фичу, хоть она и проста. Из-за отсутствия казалось бы логичной функции, нет возможности сделать удобный функционал на проекте — онлайн трансляцию мероприятий посредством Вконтакте.
Чего уж тут говорить о более глобальных просьбах…
Чего уж тут говорить о более глобальных просьбах…
Ну, так не молчать же теперь? Вода, как известно, камень точит. Я как раз очень хотел бы поменять сложившийся порядок вещей усилием коллективного разума. Потому мне дико обидно, что статья в районе нуля по рейтингу колеблется. Всем по фиг, получается? =)
Я наоборот, только за! =)
Ну, ИМХО, ВК несколько лет назад и сегодня — все таки разные вещи. Субъективно, разработчики стали куда отзывчивее. Да и изменения какие-никакие, а происходят. Хотя бы переработка раздела для разработчиков — уже хорошо. Плюс ко всему, исчерпан кредит у ВК или нет, а разумной альтернативы для российского рынка нет. Поэтому нужно как-то все таки подтолкнуть ВК к диалогу…
Альтернатива в плане аудитории. В FB или G+ обитают все таки определенные группы людей, часто не пересекающиеся с VK. Не важно какую нагрузку содержит ваш проект: информационную или коммерческую, — если вы нацелены на российский рынок и вам важно продвижение в социальных сетях или прямая работа с ними, то вам просто необходим ВК. Где вы быстрее всего найдете, скажем, студента ТвГУ 22 лет? Одноклассники в этом, понятно дело, не конкурент ни разу. Такая вот монополия и дает разработчикам возможность игнорировать любые просьбы со стороны сообщества.
Спам и рекламу я тоже не люблю =) Речь шла о продвижении, скажем, интернет-магазинов, блогов, социальных сервисов. Короче, тех вещей, что ориентированы на социальную составляющую априори.
Простой пример. Я сам веду блог. Написав пост, я копирую первый абзац + заголовок в ВК. Так большая часть моих читателей узнает о новостях, не мониторя сам блог и не подписываясь на RSS, которым не пользуются один фиг. Предположим, я хочу делать репост в отложенном режиме через очередь, чтобы не грузить сайт, завязываясь в обработке POST-запроса в контроллере на внешний сервис — ВК. Но не могу же! Мне нужен токен, который мне не дадут… Почему?
Простой пример. Я сам веду блог. Написав пост, я копирую первый абзац + заголовок в ВК. Так большая часть моих читателей узнает о новостях, не мониторя сам блог и не подписываясь на RSS, которым не пользуются один фиг. Предположим, я хочу делать репост в отложенном режиме через очередь, чтобы не грузить сайт, завязываясь в обработке POST-запроса в контроллере на внешний сервис — ВК. Но не могу же! Мне нужен токен, который мне не дадут… Почему?
>> Вот тут как-раз появляется вопрос: для чего? Какой смысл? Ведите тогда полностью в ВК.
Потому что я часто пишу на технические темы, где требуется подсветка синтаксиса? Потому что я использую Git для версионирования постов? Потому что я использую Markdown для форматирования?
>> Я пользуюсь rss. И пользуюсь активно.
В моем случае аудитория делится строго на два типа: программисты и непрограммисты. Первые часто подписываются на RSS. Вторые им просто не пользуются, но с удовольствием читают истории из жизни или мысли в слух.
>> Т.е., вы заставляете их читать о новостях Вашего сайта не зависимо от того, хотят они это или нет?
Это, мне кажется, вопрос привычки пользоваться социальными сетями vs пользоваться rss. Моя новостная лента формируется моими друзьями и теми, на кого я подписан, потому что они, очевидно, мне интересны. Думаю, с теми, кто подписан на меня ситуация обстоит так же. Если мне что-то не интересно, я просто нажимаю крестик в верхнем левом углу новости. Тогда она больше не мешается.
>> Потому, что не надо так делать! Еще раз: хотите публиковать — делайте ручками
Я программист. По определению не люблю что-то делать ручками. Но даже в нетехнической аудитории люди быстро подхватывают такую манеру. То есть функционал востребован аудиторией. Как можно сказать, что он не нужен? Не нужен кому?
Потому что я часто пишу на технические темы, где требуется подсветка синтаксиса? Потому что я использую Git для версионирования постов? Потому что я использую Markdown для форматирования?
>> Я пользуюсь rss. И пользуюсь активно.
В моем случае аудитория делится строго на два типа: программисты и непрограммисты. Первые часто подписываются на RSS. Вторые им просто не пользуются, но с удовольствием читают истории из жизни или мысли в слух.
>> Т.е., вы заставляете их читать о новостях Вашего сайта не зависимо от того, хотят они это или нет?
Это, мне кажется, вопрос привычки пользоваться социальными сетями vs пользоваться rss. Моя новостная лента формируется моими друзьями и теми, на кого я подписан, потому что они, очевидно, мне интересны. Думаю, с теми, кто подписан на меня ситуация обстоит так же. Если мне что-то не интересно, я просто нажимаю крестик в верхнем левом углу новости. Тогда она больше не мешается.
>> Потому, что не надо так делать! Еще раз: хотите публиковать — делайте ручками
Я программист. По определению не люблю что-то делать ручками. Но даже в нетехнической аудитории люди быстро подхватывают такую манеру. То есть функционал востребован аудиторией. Как можно сказать, что он не нужен? Не нужен кому?
>> Мне, например, было бы совсем не интересно читать (...)
По всей видимости именно поэтому вы не пользуетесь социальными сетями. То, что мне не интересно, я игнорирую или убираю из ленты. Например, кулинарные группы исчезли оттуда навсегда. Некоторые особо активные люди — тоже.
>> Наркотики и оружие тоже очень востребовательны
Слишком широкая аналогия, но сыграю по вашим правилам =) Вы можете получить доступ и к тому и к другому, если у вас есть на то причины. Да, вы должны отвечать определенным требованиям: адекватность, отсутствие судимости, пригодность. Но если вы охотник, то вам выдадут разрешение на владение и ношение, если охранник или представитель правоохранительных органов — тоже. А вот к описанным мной функциям «невозможно ни при каких условиях» допуститься. Только про ядерное оружие не нужно аналогий, ок? ^_^
>> Какой от этого смысл ВК? Зачем им боты, а не люди?
Боты — это роботы на службе у людей. В позитивном случае, разумеется. Боты могут снабжать пользователей (читай, людей) полезной информацией, которая привлечет их в социальную сеть. Если лента новостей в ВК дает вам все, что нужно, почему бы не заглядывать в нее чаще? Фишка состоит в том, что такого рода приложения могут предложить пользователям полезные функции, до которых у ВК просто руки не доходят или идеи такой не возникало. Нельзя отсавлять все без контроля. Но я не считаю правильным и закрывать все наглухо. Иначе будет так
По всей видимости именно поэтому вы не пользуетесь социальными сетями. То, что мне не интересно, я игнорирую или убираю из ленты. Например, кулинарные группы исчезли оттуда навсегда. Некоторые особо активные люди — тоже.
>> Наркотики и оружие тоже очень востребовательны
Слишком широкая аналогия, но сыграю по вашим правилам =) Вы можете получить доступ и к тому и к другому, если у вас есть на то причины. Да, вы должны отвечать определенным требованиям: адекватность, отсутствие судимости, пригодность. Но если вы охотник, то вам выдадут разрешение на владение и ношение, если охранник или представитель правоохранительных органов — тоже. А вот к описанным мной функциям «невозможно ни при каких условиях» допуститься. Только про ядерное оружие не нужно аналогий, ок? ^_^
>> Какой от этого смысл ВК? Зачем им боты, а не люди?
Боты — это роботы на службе у людей. В позитивном случае, разумеется. Боты могут снабжать пользователей (читай, людей) полезной информацией, которая привлечет их в социальную сеть. Если лента новостей в ВК дает вам все, что нужно, почему бы не заглядывать в нее чаще? Фишка состоит в том, что такого рода приложения могут предложить пользователям полезные функции, до которых у ВК просто руки не доходят или идеи такой не возникало. Нельзя отсавлять все без контроля. Но я не считаю правильным и закрывать все наглухо. Иначе будет так
>> Пока, ни один бот не смог определить мои интересы. Ваш тоже не сможет, уверяю ;).
Смотрите. Как активный пользователь социальной сети, я хочу видеть в своей новостной ленте анонсы постов из блогов. Но этого не сделать, потому что на токен наложен странный запрет. Как активный пользователь социальной сети, я хочу получать уведомления о поступлении товара, на который сделал предзаказ в интернет-магазине, в личные сообщения. Но не будут же представители магазина это делать руками, верно? А автоматически при смене статуса товара этого не сделать, потому что… Ну вы поняли суть моей мысли =)
>> Я тоже не считаю так. Даже больше — мне нет дела до ВК
Не всем вышеописанное нужно. Но многим бы не помешало. Однако никакой возможности сделать нет. Плохо, согласны?
Смотрите. Как активный пользователь социальной сети, я хочу видеть в своей новостной ленте анонсы постов из блогов. Но этого не сделать, потому что на токен наложен странный запрет. Как активный пользователь социальной сети, я хочу получать уведомления о поступлении товара, на который сделал предзаказ в интернет-магазине, в личные сообщения. Но не будут же представители магазина это делать руками, верно? А автоматически при смене статуса товара этого не сделать, потому что… Ну вы поняли суть моей мысли =)
>> Я тоже не считаю так. Даже больше — мне нет дела до ВК
Не всем вышеописанное нужно. Но многим бы не помешало. Однако никакой возможности сделать нет. Плохо, согласны?
Если вы хотите получать личные сообщения, вам не нужно выполнять привязку приложения к своей учетной записи — это делают разработчики магазина. Насколько я понимаю, вам, как пользователю, достаточно выполнить авторизацию в магазине через ВКонтакте — магазин получит ваш User ID и отправит сообщение (если доступ к личным сообщениям открыт). Но тут уже вступает в силу ограничение на количество сообщений (в сутки), которые можно отправить пользователям не из списка друзей, но это, как говорится, совсем другая история :)
Воооот, в этом и состоит вся соль =) Дело в том, что магазин не сможет получить токен для автоматической оптравки сообщений через «свой» аккаунт в ВК мне, потому что он, очевидно, является веб-приложением. Встроить возможность оптравки сообщений через ВК в e-commerce движок просто невозможно из-за описанного мной в посте ограничения! =)
Ну если магазин один, то, думаю, один раз скопировать токен из адресной строки — не проблема. А если вы предоставляете некий плагин, который может такое делать — тогда да, печаль.
Лично я пытался сделать подобную функциональность в виде плагина для Spree. Не получилось. Потом наступил на те же самые грабли еще в двух-трех задумках. И мне показалось, что как-то они часто попадаются…
По поводу «я хочу видеть в своей новостной ленте анонсы постов из блогов» и т. д. Можно сделать standalone-приложение, предназначенное для владельцев блогов, представителей магазина и т. д. И они будут с помощью этого приложения рассылать уведомления
А потом поддерживать это приложение, собирать его под разные ОС, не забывать фиксить баги… И это все вместо одной страницы в админке. Конечный пользователь в итоге страдает от недополучения услуги, разработчики — от того, что не могут реализовать все по-человечески. Кто выиграл-то от текущей политики? Вот чего я понять никак не могу.
Согласитесь, что костыль. Причем требующий усилий и от разработчика, и от пользователей.
Всё-таки недостаток вк в том, что нельзя быть «другом», но не подписчиком. Очень многие используют вк как единственное средство персональной коммуникации (не считая телефонной связи) и чтобы оставаться с ним «в контакте» нужно терпеть «спам» с их новыми фоточками, записями на «стену» и т. п.
Открою вам тайну =) Можно. Нажмите на «крестик» у любой новости, нажмите «Не показывать новости %username%» и все. Можете общаться, но не читать, что человек постит на стену =)
Дык в новостях можно отключать людей. То есть тупо в новостях есть список с галочками. Ставишь там галочки напротив людей, новости которых ты хочешь читать
Кстати, у сообществ ВК есть возможность подключить импорт записей на стенку через RSS. Подключается в индивидуальном порядке через техподдержку. Условие — вроде бы 10 подписчиков и более (или 100, точно не помню).
Интересная новость, спасибо =) Но блог — это частный случай, который мне первым пришел в голову, потому что сталкиваюсь с этим каждый день почти. Более сложная логика в RSS не умещается. Личные сообщения для вот таких случаев вообще не доступны…
Большинство активных пользователей соцсетей в России прежде всего проводят время в VK, а многие из них только в нём, а в других даже не зарегистрированы или крайне редко туда заходят. И отчасти дело даже не в том, что «Дуров украл идею и дизайн и занял рынок первым, а хомячки инертны», а в том, что сейчас vk предоставляет сервисы, которых у конкурентов либо нет, либо они неполноценны. Имхо, vk сумел развить идеи и дизайн fb лучше чем сам fb. Может на то были объективные причины (скажем разница американского и российского законодательства, а также обязательность его исполнения, или разница в пресловутом менталитете), а может субъективные (Дуров лучше понял, что нужно пользователям), но факт остается фактом — если хочешь выпустить соцприложение для российского рынка не для галочки, а желая иметь максимальное число пользователей (для получения прибыли, удовлетворения ЧСВ или из альтруизма — не суть), то нужно его выпускать под vk, а уж потом смотреть на другие сети как российские, так и международные.
1. Вы правы. Для меня самый активный слой населения — те самые студенты. Они потребляют информацию, товары, услуги, не выходя из социальных сетей. Да, нужно делать выбор, исходя из потребностей. В названных вами сегментах нет равных ВК социальных сетей.
2. Ограничения накладываются на вызов тех или иных методов API строго из веб-приложений. Приложения, работающие внутри ВК или являющиеся standalone-программами (мобильные или десктопные) никаких преград не имеют. Это мне и непонятно.
2. Ограничения накладываются на вызов тех или иных методов API строго из веб-приложений. Приложения, работающие внутри ВК или являющиеся standalone-программами (мобильные или десктопные) никаких преград не имеют. Это мне и непонятно.
Кто сказал, что увожу пользователей из сети, а не привлекаю их туда? o_O Чтобы пользоваться моим приложением, нужно иметь аккаунт в ВК, как минимум. И кто сказал, что мобильное/десктопное приложение работает на благо сети? Разделение идет по классу, а не по функциональности, увы.
Ну, положа руку на сердце, дальняя цель адаптации нашего веб-приложения под ВК — именно увести пользователей с ВК из-за «грабительских» условий их платежного сервиса. Проще говоря, нам нужна аудитория ВК, нужен низкий порог входа для неё, но не нужны их платежные сервисы. Ничего личного (если не считать Хабр соцсетью, то больше всего я лично пользуюсь ВК), просто бизнес.
1. Я не маркетолог и у нас в штате его нет. Наша ЦА — те, кому нужно наше приложение. Статистика текущих пользователей (если верить данным о дате рождения, поле и т. п.) не позволяет выделить какую-то ЦА и под неё искать соцсеть или иной способ продвижения. Исходя из общих представлений о статистике — чем больше аудитория сервиса, тем больше в ней нашей ЦА.
2. Для меня давно нет разницы между веб и невеб приложением. В смысле есть, но чисто технологическая, но даже чистую статику, раздаваемую по http без признаков JS или иного активного содержимого, я считаю приложением, поскольку я пишу код, реализующий бизнес-логику и/или пользовательские сценарии, пускай они и очень примитивны, но всё же сложнее hello world, который часто приводится как пример простейшего приложения. Даже единственная заглушка «сайт находится в разработке, зайдите года через два» сложнее как правило.
2. Для меня давно нет разницы между веб и невеб приложением. В смысле есть, но чисто технологическая, но даже чистую статику, раздаваемую по http без признаков JS или иного активного содержимого, я считаю приложением, поскольку я пишу код, реализующий бизнес-логику и/или пользовательские сценарии, пускай они и очень примитивны, но всё же сложнее hello world, который часто приводится как пример простейшего приложения. Даже единственная заглушка «сайт находится в разработке, зайдите года через два» сложнее как правило.
Вообще, это ошибка.
Ошибкой было бы выбором в качестве ЦА тех, кому наше приложение не интересно в принципе. Скажем, «Домохозяйки 90 лет, имеющие меньше 1000 рублей дохода в месяц». А так мы нашу ЦА не терям, просто не можем на ней сфокусироваться. Имхо, это не ошибка, а погрешность (извините, мне эти термины очень привычны и четко чувствую разницу между ними).
Т.е., проще говоря — вы сами не знаете для кого создали приложение? Ок. )
Для геймеров :)
Эмм… В Китае 1.5 млрд. человек, но вряд ли стоит делать русскоязычное приложение для них, верно?/blockquote>
Столь грубое разфокусирование мы не допустили, ориентировались только на русскоязычных (и именно поэтому vk, не fb). А так среди нынешних пользователей есть и мужчины, и женщины, возраст от 12 до 70 и т. п. Ну не гистограммы же строить, доверительные интервалы определять и вычислять коэффициенты корреляции ради маркетинга. Нельзя так опошлять вероятностно-статические методы в информационно-измерительной технике :)
Стоп! Вы берете в расчет уже не ЦА, а текущих пользователей. Вам нужны новые пользователи, но вы ориентируетесь на текущих (читай — случайных)? )
Не совсем случайных. Случайных мы набираем рекламными кампаниями практически без таргетирования, а смотрим тех, кто хотя бы месяц поиграл.
Какой смысл бить артиллерией по большой площади, когда можно сделать точечную бомбардировку? )
Большая сложность точечной бомбардировки. В частности нужны целеуказатели и/или корректировщики.
Смешивать продажи и тех.производство тоже не стоит ;).
Никто и не смешивает :) Продажи, по сути, пущены на самотек. Но совсем ими не заниматься, увы, не получается. Каждому технарю приходится торговать и если не продавать (свое приложение или свой труд — не суть), так покупать тех, кто сможет продавать.
Как-то у FB таких проблем не возникает, после работы с FB, TW, LI появилась необходимость в VK, и я столкнулся со всеми проблемами, которые описаны в посте, и я полностью поддерживаю автора!
Единственный выход, который вижу, делать мобильное приложение, и через него просить клиента авторизироваться, чтобы получить offline токен, а дальше уже с серверной стороны работать именно с этим токеном, но еще такой вариант поока не проверил )
Единственный выход, который вижу, делать мобильное приложение, и через него просить клиента авторизироваться, чтобы получить offline токен, а дальше уже с серверной стороны работать именно с этим токеном, но еще такой вариант поока не проверил )
Вероятно они просто опасаются НСД к данным пользователя. В случае десктоп или мобильных приложений обмен идёт непосредственно с девайсом пользователя и пользователь может (в теории) принять меры, запрещающие приложению обмениваться трафиком с какими-то другими сайтами в Сети, в конце-концов это его зона ответственности: если его девайс получил какие-то данные от vk, а потом их отправил куда-то ещё, то vk тут не причём. А вот если vk отдаст данные серверу третьей стороны, а тот выполнит что-то, кроме того, что пользователь ожидает, то позиция vk будет более сомнительной не только с точки зрения морали, но и с точки зрения права, если дело дойдёт до гражанского иска, а то и уголовное дело может быть.
Разрешая доступ к своим данным, пользователь соглашается на некоторый риск. Только с его согласия ВК отдает данные третьей стороне. Различия между вебом и десктопом/мобильным сейчас весьма и весьма тонки, согласитесь? Так что «зоны ответственности» на основе класса приложения тут выделить не получится. Сомневаюсь, что, в случае каких-то фейлов, шишки полетят в ВК. За то, что творит приложение, отвечает его разработчик. Возможно, дополнительный уровень контроля (проверка ребятами из ВК? пользовательское ревью?) за теми, кто использует расширенное API, и не помешает.
Еще одна деталь, на которую хочу обратить внимание: мы с вами гадаем, почему так сделано. Видим, что костыль, но откуда он? Разработчики могут дать на этот вопрос полный ответ, что, вполне возможно, решило бы все споры. Но они молчат =)
Еще одна деталь, на которую хочу обратить внимание: мы с вами гадаем, почему так сделано. Видим, что костыль, но откуда он? Разработчики могут дать на этот вопрос полный ответ, что, вполне возможно, решило бы все споры. Но они молчат =)
С точки зрения логики и технологий вы может и правы, но с точки зрения закона есть большая разница между «вк отдал ПДн пользователя ему же, а третьи лица (разработчики) с его девайса их украли» и «вк отдал ПДн пользователя третьим лицам (разработчикам), пускай и с согласия пользователя, а те их разгласили». Если в случае утечки пользователь подаст иск на вк, то в первом случае с большой вероятностью суд сменит ответчика в иске, а если пользователь подаст в суд на разработчиков, то во втором, пускай у вк даже останется право регрессного иска к разработчикам. Одно дело участвовать в деле как свидетель и другое как ответчик.
Даже чисто репутационные потери если смотреть. Представьте себе на Хабре пост "%username% подал в суд на VK, но суд решил, что виноваты разработчики приложения, а не VK". И пост "%username% подал в суд на VK, суд решил что VK виновен", а за ним пост «VK подал в суд на разработчиков». Уверен, что у большинства в голове отложится прежде всего второй пост «VK — бяки, даже наш „самый справедливый“ суд решил, что они виновны», а потом ещё и третий «VK — дважды бяки, суд уже решил, что они виновны, а они теперь бедных разработчиков хотят выставить козлами отпущения за свои косяки».
Даже чисто репутационные потери если смотреть. Представьте себе на Хабре пост "%username% подал в суд на VK, но суд решил, что виноваты разработчики приложения, а не VK". И пост "%username% подал в суд на VK, суд решил что VK виновен", а за ним пост «VK подал в суд на разработчиков». Уверен, что у большинства в голове отложится прежде всего второй пост «VK — бяки, даже наш „самый справедливый“ суд решил, что они виновны», а потом ещё и третий «VK — дважды бяки, суд уже решил, что они виновны, а они теперь бедных разработчиков хотят выставить козлами отпущения за свои косяки».
Ну, вполне возможно. На юридическое поле битвы вылезать не буду: я там безоружен =) Но грызет меня смутное сомнение, что не в этом основная причина. Попробую сделать хитрый ход конем, и призвать в пост antanubis — единственного разработчика из команды VK, которого я знаю на Хабре.
(нифига себе, работает..)
Вообще, логику работы API я не определял, но исторически все примерно так (как я это понимаю, типа личный взгляд): есть веб-приложения и десктоп приложения. Веб-приложениям мы разрешаем то, решение о разрешении чего мы готовы возложить на пользователя (кривая формулировка, но вроде бы так). Разрешение на доступ к личным сообщениям (самый главный пример, наверное) — это то решение, которое доверить пользователю мы не готовы.
(только вот давайте без этой туфты про «это же данные пользователя! как вы за него решаете! вдруг он хочет сам отдать свои сообщения на растерзание всем нехорошим людям этого мира!» — все так, для этого есть standalone приложения, вирусы, которым он может хоть номера своих кредиток слить, и т.д.)
Можно конечно говорить «Но ведь как же? Его же спрашивают разрешение! Он сам дает доступ!», но как мне кажется, урон от необдуманных решений по доступу к личным сообщениям для сторонних приложений будет значительно выше получаемого профита. То есть веб — это такая песочница, люди там совсем невнимательно читают что-то и нажимают кнопки, соглашаются со всем и т.д. и какую бы кричащую предупреждающую плашку в боксе разрешения мы не повесили — все будут не читая пропускать, потому что сейчас цель у них — получить доступ к тому, к чему они пытаются, и никакие окошки их не остановят.
Теперь на счет десктоп — та логика, в принципе, та же, за исключением того, что бессмысленно ставить ограничения :) Потому что если пользователя убедили установить себе бинарник, то от плохих ребят его уже ничего не спасет — он установил уже себе снифер, кейлогер, вирус, что угодно… Поэтому десктоп пусть работает через API, делает клиенты — там нечего особо защищать. И если для доступа к сайту, к примеру, от юзера требуется не в окошке нажать «Разрешаю», а скачать и установить какой-то софт, то это сдерживает все же значительно больше народу — а главное, если не сдерживает это, то уже ничего не поможет.
+ не надо забывать, что сторонние сайты, будучи быть может хорошими приложениями сами по себе, легко могут иметь XSS-уязвимости, в результате чего доступ ко всему разрешенному получит еще кто угодно… и если бы им было все разрешено, они конечно бы каялись и клялись, что все исправили и верните, пожалуйста, доступ… ну и действительно, XSS — бывает же, чего там, казнить за это приложение навсегда как-то странно… однако разовый договоренный допуск такой XSS может принести очень не мало денег и будет очень соблазнителен приложениям с точки зрения монетизации — и это все аргумент, опять же неактуальный для десктоп софта.
То есть приложение, которому можно давать доступ ко всему, потому что оно и так имеет доступ ко всему, если захочет — это, по определению, и есть те, кто могут вытащить токен из oauth.vk.com/blank.html
Так и получилось разделение на два класса методов. Ну а потом десктоп-разрешения переехали в мобайл. И вряд ли это в ближайшее время изменится (хотя кто знает?..) То есть можно обсуждать перенос конкретных методов из расширенных в обычные (которые туда типа случайно попали), хотя обсуждать все конкретные методы лично мне, например, некогда. А вот отмену всей схемы — едва ли.
Вообще, логику работы API я не определял, но исторически все примерно так (как я это понимаю, типа личный взгляд): есть веб-приложения и десктоп приложения. Веб-приложениям мы разрешаем то, решение о разрешении чего мы готовы возложить на пользователя (кривая формулировка, но вроде бы так). Разрешение на доступ к личным сообщениям (самый главный пример, наверное) — это то решение, которое доверить пользователю мы не готовы.
(только вот давайте без этой туфты про «это же данные пользователя! как вы за него решаете! вдруг он хочет сам отдать свои сообщения на растерзание всем нехорошим людям этого мира!» — все так, для этого есть standalone приложения, вирусы, которым он может хоть номера своих кредиток слить, и т.д.)
Можно конечно говорить «Но ведь как же? Его же спрашивают разрешение! Он сам дает доступ!», но как мне кажется, урон от необдуманных решений по доступу к личным сообщениям для сторонних приложений будет значительно выше получаемого профита. То есть веб — это такая песочница, люди там совсем невнимательно читают что-то и нажимают кнопки, соглашаются со всем и т.д. и какую бы кричащую предупреждающую плашку в боксе разрешения мы не повесили — все будут не читая пропускать, потому что сейчас цель у них — получить доступ к тому, к чему они пытаются, и никакие окошки их не остановят.
Теперь на счет десктоп — та логика, в принципе, та же, за исключением того, что бессмысленно ставить ограничения :) Потому что если пользователя убедили установить себе бинарник, то от плохих ребят его уже ничего не спасет — он установил уже себе снифер, кейлогер, вирус, что угодно… Поэтому десктоп пусть работает через API, делает клиенты — там нечего особо защищать. И если для доступа к сайту, к примеру, от юзера требуется не в окошке нажать «Разрешаю», а скачать и установить какой-то софт, то это сдерживает все же значительно больше народу — а главное, если не сдерживает это, то уже ничего не поможет.
+ не надо забывать, что сторонние сайты, будучи быть может хорошими приложениями сами по себе, легко могут иметь XSS-уязвимости, в результате чего доступ ко всему разрешенному получит еще кто угодно… и если бы им было все разрешено, они конечно бы каялись и клялись, что все исправили и верните, пожалуйста, доступ… ну и действительно, XSS — бывает же, чего там, казнить за это приложение навсегда как-то странно… однако разовый договоренный допуск такой XSS может принести очень не мало денег и будет очень соблазнителен приложениям с точки зрения монетизации — и это все аргумент, опять же неактуальный для десктоп софта.
То есть приложение, которому можно давать доступ ко всему, потому что оно и так имеет доступ ко всему, если захочет — это, по определению, и есть те, кто могут вытащить токен из oauth.vk.com/blank.html
Так и получилось разделение на два класса методов. Ну а потом десктоп-разрешения переехали в мобайл. И вряд ли это в ближайшее время изменится (хотя кто знает?..) То есть можно обсуждать перенос конкретных методов из расширенных в обычные (которые туда типа случайно попали), хотя обсуждать все конкретные методы лично мне, например, некогда. А вот отмену всей схемы — едва ли.
(сам в шоке: пентаграмму-то я забыл нарисовать)
Пожалуй, в чем-то вы правы. Хотя уязвимостям, кривой работе и хаку десктопные/мобильные программы подвержены ничуть не меньше веб-приложений. К тому же установка очередного APK из маркета на Android так проста и естественна, что вряд ли этот процесс остановит того, кто в вебе нажимает на все подряд кнопки… Ну да фиг с ним.
Но текущая политика запрета — это все равно тупик. Мы (и разработчики, и пользователи) упорно лезем в веб. Писать десктопные приложения становится все менее выгодно, если не говорить об играх, спец. софте и тому подобных областях. Поддерживать их — мука. Вконтакте используется не только вместо чата, блога и хранилища фотографий. Он еще и очень удобное место для ведения торговли, обмена или заключения сделок. Социальные сети — это моделирование «реальных» (в смысле «away from a keywboard») отношений. А в них есть место коммерции и различным услугам. Поэтому они перекочевали и в ВК.
Возможно, имеет смысл добавить в профиль пользователя настройку «Максимально возможные права», которую по умолчанию ставить в «Standalone делает, что угодно, вебу — нельзя ничего» (утрирую, конечно). Может быть было бы неплохо ввести отдельные аккаунты «для бизнеса», которые будут представлять различные организации и интернет-магазины. Факт состоит в том, что как-то менять текущую модель точно нужно, потому что из-за нее буксуем, господа =)
Пожалуй, в чем-то вы правы. Хотя уязвимостям, кривой работе и хаку десктопные/мобильные программы подвержены ничуть не меньше веб-приложений. К тому же установка очередного APK из маркета на Android так проста и естественна, что вряд ли этот процесс остановит того, кто в вебе нажимает на все подряд кнопки… Ну да фиг с ним.
Но текущая политика запрета — это все равно тупик. Мы (и разработчики, и пользователи) упорно лезем в веб. Писать десктопные приложения становится все менее выгодно, если не говорить об играх, спец. софте и тому подобных областях. Поддерживать их — мука. Вконтакте используется не только вместо чата, блога и хранилища фотографий. Он еще и очень удобное место для ведения торговли, обмена или заключения сделок. Социальные сети — это моделирование «реальных» (в смысле «away from a keywboard») отношений. А в них есть место коммерции и различным услугам. Поэтому они перекочевали и в ВК.
Возможно, имеет смысл добавить в профиль пользователя настройку «Максимально возможные права», которую по умолчанию ставить в «Standalone делает, что угодно, вебу — нельзя ничего» (утрирую, конечно). Может быть было бы неплохо ввести отдельные аккаунты «для бизнеса», которые будут представлять различные организации и интернет-магазины. Факт состоит в том, что как-то менять текущую модель точно нужно, потому что из-за нее буксуем, господа =)
Я понимаю, что к мобильным приложениям эта логика прикладывается чуть хуже, чем к десктопным — но они и появились позднее, к ним просто ее применили готовую. Ну и ограничения нельзя делать для мобильных приложений просто потому что там _необходимы_ полноценные клиенты :) Чего не скажешь о вебе.
Но уязвимости и хаки десктоп-приложений доступны тоже только другим десктоп приложениям, которые сами по себе могут быть просто тупо плохими. Что слегка обессмысливает весь процесс.
А зачем вам в веб приложениях коммерции и услуг доступ к личным сообщениям пришедшего к вам и авторизующегося у вас пользователя? О_о
Но уязвимости и хаки десктоп-приложений доступны тоже только другим десктоп приложениям, которые сами по себе могут быть просто тупо плохими. Что слегка обессмысливает весь процесс.
А зачем вам в веб приложениях коммерции и услуг доступ к личным сообщениям пришедшего к вам и авторизующегося у вас пользователя? О_о
Давайте рассмотрим одну из тех ситуаций, которые, собственно говоря, привели к этому посту.
- Есть интернет-магазин на основе e-commerce платформы.
- Вход покупателей выполняется через стандартную аутентификацию ВК. Это удобно, потому что не требует от пользователя никаких усилий, чтобы пройти регистрацию и купить. Таким образом, мы знаем uid пользователя, но не более того: у нас нет почтового адреса, нет мобильного. Способ связи логичен — ВК. Он для того и создан — общаться.
- Человек в вашем магазине купил товар, которого нет в наличии. Сделал предзаказ.
- Мы бы хотели отправить ему личное сообщение: «Парень! Товар прибыл на склад!», — когда нужный ему товар появился в наличии
- Для этого заводим этакий «бизнес-аккаунт» в ВК с именем «Супер Крутой Магазин»
- Пытаемся дать нашему e-commerce движку доступ к отправке сообщений от имени этого аккаунта
- Не можем этого сделать, потому что мы являемся веб-приложением =(
- Плачем ='(
Ну это совсем другая ситуация, да. По обсуждению-то получается, что хочется иметь возможность запросить доступ к личке любого пользователя, что нонсенс для более 95% добропорядочных приложений. Это же другая проблема — проблема цивилизованного способа выдачи полноценного токена конкретному юзеру, скажем, админу приложения или еще кому-нибудь…
Сейчас действительно можно сделать это через копирование токена из blank.html — но надо понимать, что это вы сами копируете для своего же приложения, а не пользователям предлагаете это делать (против чего мы собственно и, например, написали текст на этом blank.html). Можно подумать, как сделать более человеческий интерфейс для этого действия…
В конце концов, это может быть вообще ваше какое-то серверное десктоп-приложение, через которое работает ваш этот робот-пользователь — к пользовательскому веб-приложению, в котором пользователь дает в браузере разрешение на доступ к каким-то своим данными этот кей автоматической отправки сообщений от своего робота ведь не имеет никакого отношения!
Сейчас действительно можно сделать это через копирование токена из blank.html — но надо понимать, что это вы сами копируете для своего же приложения, а не пользователям предлагаете это делать (против чего мы собственно и, например, написали текст на этом blank.html). Можно подумать, как сделать более человеческий интерфейс для этого действия…
В конце концов, это может быть вообще ваше какое-то серверное десктоп-приложение, через которое работает ваш этот робот-пользователь — к пользовательскому веб-приложению, в котором пользователь дает в браузере разрешение на доступ к каким-то своим данными этот кей автоматической отправки сообщений от своего робота ведь не имеет никакого отношения!
>> По обсуждению-то получается, что хочется иметь возможность запросить доступ к личке любого пользователя
За переписку и чтение личных данных все утекло само собой, как это всегда бывает =)
>> Это же другая проблема — проблема цивилизованного способа выдачи полноценного токена конкретному юзеру
Понимаете, в данном случае я не интренет-магазин разрабатываю, а движок. Пользователи движка — владельцы магазинов. Они хотят, чтобы было просто. Им нужен интерфейс в админке и все. Включить, указать аккаунт, подтвердить права. Но из-за ограничений я начинаю делать хаки: просить их копировать/вставлять URL, поставлять дополнительное приложение…
>> Можно подумать, как сделать более человеческий интерфейс для этого действия…
Собственно, к началу диалога с парнями из ВК я и пытаюсь подойти этим постом. Иного способа у меня не было. Пришлось призывать вас ^_^
За переписку и чтение личных данных все утекло само собой, как это всегда бывает =)
>> Это же другая проблема — проблема цивилизованного способа выдачи полноценного токена конкретному юзеру
Понимаете, в данном случае я не интренет-магазин разрабатываю, а движок. Пользователи движка — владельцы магазинов. Они хотят, чтобы было просто. Им нужен интерфейс в админке и все. Включить, указать аккаунт, подтвердить права. Но из-за ограничений я начинаю делать хаки: просить их копировать/вставлять URL, поставлять дополнительное приложение…
>> Можно подумать, как сделать более человеческий интерфейс для этого действия…
Собственно, к началу диалога с парнями из ВК я и пытаюсь подойти этим постом. Иного способа у меня не было. Пришлось призывать вас ^_^
Замечание здравое (я о сабже в целом), но очевидно что если мы просто разрешим досуп ко всему апи всем приложениям — начнется хаос и анархия, ведь тогда можно будет смело писать под формой авторизации на своем сайте "* авторизовываясь через ВКонтакте я соглашаюсь разослать всем своим друзьям приглашения на этот сайт". Поэтому я считаю что доступ к личным сообщениям (и другим методам аналогичного уровня приватности) вэб приложениям мы не дадим. На счет примера выше, со связью с пользователем — это должно быть реализовано как-то иначе без доступа к личке. FB решил эту проблему отдавая email. Со временем и мы тоже сможем так делать, (когда процент пользователей для которых email является логином существенно упадет).
В завершение хочу привести небольшой пример того на сколько все плохо в мире: многие сервисы для того чтобы обходить обсуждаемое ограничение просили скопировать токен из адресной строки в специальную форму. Во сновном так делали сервисы для управления пабликами, и создания расписания постов там. Так вот нам пришлось вставить предупреждение в blank.html, так как даже эти честные на первый взгляд сервисы, пользователи которых являются довольно прошаренными и понимают что к чему — злоупотребляли спамом через полученные токены.
В завершение хочу привести небольшой пример того на сколько все плохо в мире: многие сервисы для того чтобы обходить обсуждаемое ограничение просили скопировать токен из адресной строки в специальную форму. Во сновном так делали сервисы для управления пабликами, и создания расписания постов там. Так вот нам пришлось вставить предупреждение в blank.html, так как даже эти честные на первый взгляд сервисы, пользователи которых являются довольно прошаренными и понимают что к чему — злоупотребляли спамом через полученные токены.
( опять сработало o_O )
>> если мы просто разрешим досуп ко всему апи всем приложениям — начнется хаос и анархия
Мне пока удовлетворяющим балансу «приватность — возможности» кажется вот это предложение. Чем оно плохо?
>> FB решил эту проблему отдавая email
Отвечу так. У меня есть знакомая девушка. Она активно пользуется ВК и легко авторизуется через него в интернет-магазинах. Но почта у нее — это просто формальность. Она туда даже не заглядывает. Основной способ коммуникации — ВК. То есть предоставление email не решит проблему. Мы от него как раз уйти пытаемся. В противном случае я мог бы просто попросить его ввести, как это делают многие сервисы.
>> если мы просто разрешим досуп ко всему апи всем приложениям — начнется хаос и анархия
Мне пока удовлетворяющим балансу «приватность — возможности» кажется вот это предложение. Чем оно плохо?
>> FB решил эту проблему отдавая email
Отвечу так. У меня есть знакомая девушка. Она активно пользуется ВК и легко авторизуется через него в интернет-магазинах. Но почта у нее — это просто формальность. Она туда даже не заглядывает. Основной способ коммуникации — ВК. То есть предоставление email не решит проблему. Мы от него как раз уйти пытаемся. В противном случае я мог бы просто попросить его ввести, как это делают многие сервисы.
на счет предложения выше — безусловно лучше чем ничего, но по опыту могу сказать что очень многие сайты будут говорить пользователю что он не может авторизоваться пока не поставит галочку (картинка с проставленной галочкой). что в итоге перевернет все в чуть менее тривиальную но такую же рутинную процедуру, так как это будет на половине сайтов пользователь привыкнет и начнется хаос и анархия, хотя попробовать так сделать я бы не отказался. Основной вопрос который останавливает – «зачем», если для связи с пользователем – то это скорее плохо чем хорошо, очень не хочется чтобы личка пользователей превратилась в помойку для спама чем для многих стал email. Любой нормальный интернет магазин кроме информации о заказе будет еще и рекламу новых товаров и акций рассылать.
>> интернет магазин кроме информации о заказе будет еще и рекламу новых товаров и акций рассылать.
Я бы сказал, что нормальный как раз и не будет. Особенно если у него будет возможность на стену того же аккаунта, что используется для отправки сообщений, выкладывать автоматически рекламу товаров, что сейчас делается всеми в ручную.
>> многие сайты будут говорить пользователю что он не может авторизоваться пока не поставит галочку
Это больше вопрос культуры. То есть вы боретесь с хамством полным техническим ограничением возможностей API, что, на мой взгляд, не очень правильно. Хотя я и могу это понять, но призываю все таки пересмотреть подход. Требование поставить галочку ничем не отличается от требования скопировать URL по сути своей.
Я бы сказал, что нормальный как раз и не будет. Особенно если у него будет возможность на стену того же аккаунта, что используется для отправки сообщений, выкладывать автоматически рекламу товаров, что сейчас делается всеми в ручную.
>> многие сайты будут говорить пользователю что он не может авторизоваться пока не поставит галочку
Это больше вопрос культуры. То есть вы боретесь с хамством полным техническим ограничением возможностей API, что, на мой взгляд, не очень правильно. Хотя я и могу это понять, но призываю все таки пересмотреть подход. Требование поставить галочку ничем не отличается от требования скопировать URL по сути своей.
Хм… А какие магазины — нормальные? Я сначала не подумал об этом, но сейчас реально если вспомнить, то от ozon-а до amazon-а и все подряд сыпят на email кучей мусора, это факт. То, что от этого мусора можно отписаться, роли не играет.
Конечно, можно начать закапываться в эту сторону. Сделать в диалоге с сообщением через API кнопку <<забанить это приложение и отправителя навсегда, почистив все за ним>>, но потом встанет вопрос поддержки всей этой ерунды в мобильных клиентах и т.д. И ведь действительно — личные сообщения не совсем email, и возможно их не стоит в него превращать.
Конечно, можно начать закапываться в эту сторону. Сделать в диалоге с сообщением через API кнопку <<забанить это приложение и отправителя навсегда, почистив все за ним>>, но потом встанет вопрос поддержки всей этой ерунды в мобильных клиентах и т.д. И ведь действительно — личные сообщения не совсем email, и возможно их не стоит в него превращать.
Да, вы правы. Личные сообщения — это не совсем email. В этом и дело. Для рекламы, анонсов, акций у магазинов есть стена в группе. На нее подписаны пользователи, которым это нужно. А спам в личку — это бан со стороны пользователя. Поэтому сообщения не шлют, если нет надобности. Хотя ничего и не мешает написать мне кому-то сообщение, так? Именно таким образом уже работает коммерция в ВК. Думаю, для вас это не новость. Есть целые сети магазинов, которые и существуют-то только в вашей Сети. Они и стали инициаторами разработки механизмов автоматизации того, что они просто-напросто делают руками. Но реализовать это не так просто, в силу причин, которые мы с вами и обсуждаем.
Опять же. Не стоит сосредотачиваться строго на личных сообщениях. Целый набор расширенных методов сильно ограничивает возможности веб-программистов: нельзя делать посты на стену собственного сообщества, нельзя удалять фотографии, нет возможности работать со списком друзей и так далее.
Тотальное ограничение — никогда не вариант. Нужно, ИМХО, пересмотреть механизм выдачи прав. Один из, на мой взгляд, разумных вариантов изменений я предложил.
Опять же. Не стоит сосредотачиваться строго на личных сообщениях. Целый набор расширенных методов сильно ограничивает возможности веб-программистов: нельзя делать посты на стену собственного сообщества, нельзя удалять фотографии, нет возможности работать со списком друзей и так далее.
Тотальное ограничение — никогда не вариант. Нужно, ИМХО, пересмотреть механизм выдачи прав. Один из, на мой взгляд, разумных вариантов изменений я предложил.
По моим наблюдениям магазины внутри нашей сети — одни из главных генераторов спама, наравне с смс-разводами :) Все эти угги, реплики часов и прочий ужас только и делают, что спамят. Ну да ладно, это уже не по теме все…
Не соглашусь. Они не только это делают. Они действительно нужны и полезны. Многие вещи, вроде ручных или каких-то заказных работ, просто нигде больше не купить. Мне лично этот вид коммерции очень симпатичен. Короче, они появились, хорошо развиваются, удобны. Значит, на то есть причины и желание пользователей. А УГ само собой сдохнет. Рынок же =)
По-моему уже в принципе пора сворачиваться =) Обсудили, проблема ясна, вы услышали. Надеюсь, что, вместе с brainfucker, и правда подумаете, попробуете внести изменения, хотя бы в порядке эксперимента, а не забудите к вечеру. Ну и я со своей стороны постараюсь не опускать руки ;)
По-моему уже в принципе пора сворачиваться =) Обсудили, проблема ясна, вы услышали. Надеюсь, что, вместе с brainfucker, и правда подумаете, попробуете внести изменения, хотя бы в порядке эксперимента, а не забудите к вечеру. Ну и я со своей стороны постараюсь не опускать руки ;)
Я бы сказал, что вообще вся схема «создать фэйковый аккаунт для оповещений через личные сообщения» — это костыль изначально.
Для внутренних приложений есть две специальных штуки: оповещения от приложений (secure.sendNotification) и запросы друзьям (showRequestBox). Мне кажется, именно к этим механизмам и надо дать доступ standalone-приложениям и все будет, как надо.
Для внутренних приложений есть две специальных штуки: оповещения от приложений (secure.sendNotification) и запросы друзьям (showRequestBox). Мне кажется, именно к этим механизмам и надо дать доступ standalone-приложениям и все будет, как надо.
Почему выдавать email пользователя можно только после того, как
?
Почему то, что у пользователя логин совпадает с email-ом — это проблема? Почему подавляющее большинство Oauth 2 провайдеров выдают email (Mail.ru, Google, yandex), а VK нет?
процент пользователей для которых email является логином существенно упадет
?
Почему то, что у пользователя логин совпадает с email-ом — это проблема? Почему подавляющее большинство Oauth 2 провайдеров выдают email (Mail.ru, Google, yandex), а VK нет?
Жутчайше бесит ограничение, согласен. Очень уж многие возможности они «обрезали».
Учитывая, что на ранних стадиях они активно подвергались атакам ботов, все оправдано. Не оставили лазеек. Я в своем приложении просто просил пользователей скопировать полный url после авторизации и получал нужные мне доступы.
Оправдано ли? Как первичная мера — ок. Но оставлять это перманентно...? А по поводу «просто просил пользователей скопировать полный url» хорошо написано на той самой странице, с которой они будут этот url копировать: oauth.vk.com/blank.html =)
Зависит от ситуации. И когда я выпускал приложение, надписи еще не было =)
Но судя по статистике людей она не пугала, у меня прекрасно был описан план действия и причины.
Но судя по статистике людей она не пугала, у меня прекрасно был описан план действия и причины.
И этот план, судя по надписи, очень не нравится разработчикам ВК =) Хотя иного выбора они не оставляют…
P.S. Кстати, довольно неплохая идея. Если учитывать специфику моего приложения, может и прокатит… Воспользуюсь, если ничего не получится с места сдвинуть. Спасибо =)
P.S. Кстати, довольно неплохая идея. Если учитывать специфику моего приложения, может и прокатит… Воспользуюсь, если ничего не получится с места сдвинуть. Спасибо =)
Вот вам ещё идея, как можно сделать: habrahabr.ru/post/179953/#comment_6266207
И ещё одна идея была в предыдущем посте: habrahabr.ru/post/179953/#comment_6265353, то есть, как я понял, виртуализировать браузер.
И ещё одна идея была в предыдущем посте: habrahabr.ru/post/179953/#comment_6265353, то есть, как я понял, виртуализировать браузер.
Увы, я потратил на это время. Контакты с разработчиками у меня есть, но они стоят на своем и правильно делают.
И будьте готовы, что если на Вас пожалуются, то приложение заблокируют.
И будьте готовы, что если на Вас пожалуются, то приложение заблокируют.
>> они стоят на своем и правильно делают
Простите, правильно делают что? Не идут навстречу собственному сообществу разработчиков?
>> И будьте готовы, что если на Вас пожалуются, то приложение заблокируют.
Поэтому я и не сторонник таких хаков. Но какой еще остается выбор?
Простите, правильно делают что? Не идут навстречу собственному сообществу разработчиков?
>> И будьте готовы, что если на Вас пожалуются, то приложение заблокируют.
Поэтому я и не сторонник таких хаков. Но какой еще остается выбор?
Правильно делают, что не дают доступ к приватным данным сторонним разработчикам.
По такой логике API получается вообще не очень нужен… Забетонировать все двери, окна, вентиляцию и даже лазейки всегда проще. Но это тормозит развитие весьма неплохих сервисов.
К тому же ничего сторонним разработчикам не мешает получить доступ к приватным данным. Просто это будет делаться куда как неудобнее, причем как для пользователей так и для этих самых сторонних разработчиков. Вместо удобной странички прямо, скажем, в админке интернет-магазина придется качать целое приложение, проходить повторную авторизацию… Это приложение нужно будет поддерживать разработчику… К чему весь этот гемморой?
К тому же ничего сторонним разработчикам не мешает получить доступ к приватным данным. Просто это будет делаться куда как неудобнее, причем как для пользователей так и для этих самых сторонних разработчиков. Вместо удобной странички прямо, скажем, в админке интернет-магазина придется качать целое приложение, проходить повторную авторизацию… Это приложение нужно будет поддерживать разработчику… К чему весь этот гемморой?
Простите, правильно делают что? Не идут навстречу собственному сообществу разработчиков?
Идут навстречу собственному сообществу пользователей (пускай они даже об этом не подозревают).
Ой ли? Как экстренная мера при борьбе со спамом полная блокировка расширенных возможностей для веб-приложений приемлима и действительно спасает пользователей от спама. Но время идет. А шагов в сторону улучшения не делается. Теперь пользователи не могут получить то, что могли бы, обрати разработчики внимание на эту проблему. С каждым годом все больше приложений переползают в веб. И им все больше требуется тесная интеграция с социальными сетями, чтобы предоставлять качественные услуги. Как быть?
>Об одном недостатке VK API вслух
Один? Серьезно?
Просто попробуйте получить ID пользователя, группы по URL его странички через api.
Хотя я благодарен всем богам, что в VK нет того ужаса, что есть в FB.
Один? Серьезно?
Просто попробуйте получить ID пользователя, группы по URL его странички через api.
Хотя я благодарен всем богам, что в VK нет того ужаса, что есть в FB.
Взять URL, вытащить оттуда последний сегмент (screen_name или id, в зависимости от настроек профиля) и засунуть его в метод users.get в качестве параметра uids? Даже токен не потребуется, вроде как… Или я чего-то не понял?
Я не говорю, что там больше нет. Я говорю, что просто только про один недостаток. Чтобы читатель не ждал, что я буду описывать все нюансы и подводные камни работы с API VK.
P.S. Что примечательно: чуть выше FB хвалят =)
Я не говорю, что там больше нет. Я говорю, что просто только про один недостаток. Чтобы читатель не ждал, что я буду описывать все нюансы и подводные камни работы с API VK.
P.S. Что примечательно: чуть выше FB хвалят =)
Похоже я пропустил момент когда появилась эта возможность :(, да и документация новая супер.
>P.S. Что примечательно: чуть выше FB хвалят =)
Это наверное Индиана Джонс, ведь для работы с FB API нужно быть археологом, а не программистом :)
>P.S. Что примечательно: чуть выше FB хвалят =)
Это наверное Индиана Джонс, ведь для работы с FB API нужно быть археологом, а не программистом :)
помойму, нужно просто чуть-чуть знать SQL, (почти) все можно получить через FQL, что нельзя вытянуть одним запросом, можно сделать через 2-3, причем все на стороне FB. Так что тут я с вами не согласен.
И даже если взять во внимание, что не все тривиально, лучше вложить больше времени в чтение документации, и получить информацию, чем её просто ни как не получить и писать приложения для всех видов мобильных маркетов )
И даже если взять во внимание, что не все тривиально, лучше вложить больше времени в чтение документации, и получить информацию, чем её просто ни как не получить и писать приложения для всех видов мобильных маркетов )
Бился с этими проблемами еще с самого начала…
Подписываюсь!
Подписываюсь!
Да, действительно очень неудобная ситуация. Мы работаем исключительно в вебе и хотели бы предоставлять пользователям возможность делать кросс-публикацию с нашего сайта в группу ВК, но без десктопного клиента не реализуешь, а просить юзеров копировать URL — тот ещё костыль.
Кстати, не знаю насчет личных сообщений, но доступ к стенке в качестве исключения они дают:
Конкретный сайт, где проходит разрешение на работу со стенкой — pruffigraph.com.
Кстати, не знаю насчет личных сообщений, но доступ к стенке в качестве исключения они дают:
Конкретный сайт, где проходит разрешение на работу со стенкой — pruffigraph.com.
Вот что странно. Социальные сети начинались как игрушка одного программиста… Таким образом, они должны лучше всех понимать потребности небольших сервисов. При этом сейчас они делают вот такие исключения только для «крупных проектов»… Просить денег с определенного уровня сообщений в единицу времени — это я могу понять…
Я являюсь автором VK-XBMC. Это клиент с открытым кодом для одноименного медиацентра. Можно слушать музыку, смотреть фотографии, и видео. Да, я стараюсь использовать АПИ вконтакта почти для всего, но авторизация это боль. Сильная боль. У меня на платформе нету браузера, вовсе. Потому приходится просить логин и пароль, авторизовывать приложения как будто из браузера, и сохранять ключи доступа. Это просто ужас, и приходится все перелопачивать как только ВК меняют авторизацию. А что поделать, такова суровая судьба. Сейчас плагином пользуется около 300 человек каждый день, в общем несколько тысяч активных пользователей.
Да, меня уже подташнивает разбираться каждый раз прикидываясь браузером.
Ссылка на плагин code.svoka.com/vk-xbmc-plugin/
Да, меня уже подташнивает разбираться каждый раз прикидываясь браузером.
Ссылка на плагин code.svoka.com/vk-xbmc-plugin/
Есть возможность авторизации по логину-паролю после согласования с администрацией.
да, я видел этот апи. Но он закрыт, и нужно получать разрешение у администрации… единственное место где это можно было попросить, что я нашел это конкурс на написание чат клиента, но это не чат клиент. Да, это было давно. Я уже более 2х лет поддерживаю плагин, может что поменялось.
Там же написано, заявки отправлять в vk.com/support
Вы поймите простую вещь: подобные ограничения делаются не назло разработчикам, а из соображений заботы о пользователях и уменьшения нежелательных для пользователя событий. Раньше ограничений было гораздо меньше: я думаю, почти все помнят нашествие спама из приложений на все стены, закончившееся баном Лицемера 2 года назад (http://roem.ru/2011/02/02/addednews18833/) и закрытием таких возможностей.
Пользователи вообще не склонны читать ограничения, которые выставляет приложение, поэтому для доступа к «расширенному» API необходимо ставить жёсткие ограничения, как минимум чтобы не было эксплуатации социальных связей со стороны приложения, а то и более жёстких вещей типа сбора приватных данных из пользовательской переписки.
Пользователи вообще не склонны читать ограничения, которые выставляет приложение, поэтому для доступа к «расширенному» API необходимо ставить жёсткие ограничения, как минимум чтобы не было эксплуатации социальных связей со стороны приложения, а то и более жёстких вещей типа сбора приватных данных из пользовательской переписки.
Это говорит лишь о том, что приложения, пользующиеся таким API, должны контроллироваться, а нарушения правил — жестоко караться. Возможно, что и тем же сообществом разработчиков. Забота о пользователях — это круто. Но в данном случае эта забота влечет ущерб для самих же пользователей: приложения, которые могли бы упростить им жизнь, просто не появляются на свет. Это как не пускать ребенка на улицу, потому что там «бибики», а потом удивляться, что он не умеет ходить через дорогу.
Контролироваться как? Хрен с ним с постингом, как быть с доступом на чтение? ВК будет раздавать личные данные пользователям третьим лицам? Пускай даже с их согласия. Представляете, на кого шишки посыпятся если, например, Лицемер сольет не только ФИО своих пользователей, но и всю их переписку? Может по морали и разработчики Лицемера виноваты будут, но возмещать ущерб будет контакт.
Рассматриваться, утверждаться. Да хотя бы приложениям с открытым исходным кодом дайте доступ! Какой-нибудь путь нужен, понимаете? К тому же ничего не мешает «злобным» разработчикам написать приложение для мобильника (ему, напомню, почему-то будут доступны все разделы API), а потом слить всю переписку. Чем веб-приложения хуже, скажите мне? И почему такого рода проблем, насколько я понимаю, нет у FB?
Такое чувство, что вы живёте в мире розовых пони. У веб-сайтов не должно быть доступа к личным сообщениям и прочим «расширенным» методам api — иначе это будет массово эксплуатироваться, вне зависимости от жёсткости контроля и степени открытости кода сайта. Те методы api, которые с оговорками можно давать другим веб-сайтам, даются узкой группе доверенных компаний — это единственный хоть сколько-то работающий способ контроля.
Что касается «злобных разработчиков мобильного приложения», они могут банально слать с вашего телефона платные СМС — поэтому там пользователи заметно внимательнее смотрят на степень доверенности приложения, чем пользователи очередного сайта, где есть удобная регистрация/авторизация через соц.сети.
Если вам действительно хочется сделать «уникальный» «инновационный» веб-сервис, вы можете попросить пользователя копировать адресную строку c blank.html, или сделать плагины к браузерам.
Что касается «злобных разработчиков мобильного приложения», они могут банально слать с вашего телефона платные СМС — поэтому там пользователи заметно внимательнее смотрят на степень доверенности приложения, чем пользователи очередного сайта, где есть удобная регистрация/авторизация через соц.сети.
Если вам действительно хочется сделать «уникальный» «инновационный» веб-сервис, вы можете попросить пользователя копировать адресную строку c blank.html, или сделать плагины к браузерам.
>> Такое чувство, что вы живёте в мире розовых пони.
А у меня такое впечатление, что вы живете в мире, где все пользователи — ну просто идиоты сущие, не понимающие что они творят напрочь =) Мой аккаунт в ВК — мое альтернативное эго в Сети. И оно должно иметь возможность взаимодействовать с виртуальными лицами, не имеющими реального человека за кадром: организацями, магазинами, сервисами. А они должны иметь возможность отвечать. Только так мы получим по-настоящему социальный веб в обозримом будущем. Пока же можно создавать только очередной редактор фоточек «а-ля Instagram».
>> поэтому там пользователи заметно внимательнее смотрят на степень доверенности приложения
Приложений в маркетах телефонов миллионы. Пользователи их ставят десятками. Регулируется процесс разработки и деплоймента приложений. Но SDK предоставляет самые максимальные возможности. На то он и SDK.
>> это единственный хоть сколько-то работающий способ контроля
Ограничение на уровне API — всегда зло. Не верите мне? Послушайте этого парня. Он как-никак разработал API для Github и с десяток оберток для самых разных сервисов. И он говорит на каждом своем выступлении: все, что может делать сам сервис, должно быть доступно через API сторонним разработчикам.
>> очередного сайта, где есть удобная регистрация/авторизация через соц.сети.
Чем очередной сайт отличается от очередного приложения из маркета?
>> вы можете попросить пользователя копировать адресную строку c blank.html, или сделать плагины к браузерам
Нарушив тем самым правила ВК и улетев в бан по первой же жалобе. Куча денег, сил и времени на ветер.
А у меня такое впечатление, что вы живете в мире, где все пользователи — ну просто идиоты сущие, не понимающие что они творят напрочь =) Мой аккаунт в ВК — мое альтернативное эго в Сети. И оно должно иметь возможность взаимодействовать с виртуальными лицами, не имеющими реального человека за кадром: организацями, магазинами, сервисами. А они должны иметь возможность отвечать. Только так мы получим по-настоящему социальный веб в обозримом будущем. Пока же можно создавать только очередной редактор фоточек «а-ля Instagram».
>> поэтому там пользователи заметно внимательнее смотрят на степень доверенности приложения
Приложений в маркетах телефонов миллионы. Пользователи их ставят десятками. Регулируется процесс разработки и деплоймента приложений. Но SDK предоставляет самые максимальные возможности. На то он и SDK.
>> это единственный хоть сколько-то работающий способ контроля
Ограничение на уровне API — всегда зло. Не верите мне? Послушайте этого парня. Он как-никак разработал API для Github и с десяток оберток для самых разных сервисов. И он говорит на каждом своем выступлении: все, что может делать сам сервис, должно быть доступно через API сторонним разработчикам.
>> очередного сайта, где есть удобная регистрация/авторизация через соц.сети.
Чем очередной сайт отличается от очередного приложения из маркета?
>> вы можете попросить пользователя копировать адресную строку c blank.html, или сделать плагины к браузерам
Нарушив тем самым правила ВК и улетев в бан по первой же жалобе. Куча денег, сил и времени на ветер.
Чем очередной сайт отличается от очередного приложения из маркета?
Read-данные предоставляются физически и юридически пользователю, а не сайту, write-доступ аналогично.
Пользователю? А, может, всё таки приложению, которое установил пользователь?
Приложение не является субъектом права. В данном случае у нас есть три субъекта: вконтакте, его пользователи и разработчики приложений. В случае десктоп или мобильного приложения данные пользователя вконтакте предоставляет пользователю (разработчики могут их получить только от пользователя, сам он им отправит, или они злоупотребят его доверием — для контакта не важно, отдавал он их пользователю), в случае веб-приложению — разработчикам (точнее администрации, но не суть, главное что не пользователю, а кому-то ещё).
Сколько вы готовы заплатить, чтобы несколько человек анализировали полностью код вашего приложения? Кстати, им ещё нужно будет предоставить доступ хотя бы read-only полностью к вашему серверу, как минимум. Просто чтобы они убедились, что вы не пишете полные логи всех http-запросов (и ответов).
«Злобным» разработчикам ничто не мешает написать такое приложение, но ответственность нести будут они как перед контактом, так и перед пользователями. А в случае веб-приложения, ответственность перед пользователем несет сам вконтакте. Почему fb это не мешает — не знаю. Может они готовы идти на такие риски, может у них законы более щадящие, может разработчики меньше законы нарушают, может ещё что. Кстати, по своему собственному интерфейсу fb предоставляет меньше доступа, чем vk. Не скажу про дро другие соцсети, но vk позволяет производить куда-более точный поиск, чем fb/
«Злобным» разработчикам ничто не мешает написать такое приложение, но ответственность нести будут они как перед контактом, так и перед пользователями. А в случае веб-приложения, ответственность перед пользователем несет сам вконтакте. Почему fb это не мешает — не знаю. Может они готовы идти на такие риски, может у них законы более щадящие, может разработчики меньше законы нарушают, может ещё что. Кстати, по своему собственному интерфейсу fb предоставляет меньше доступа, чем vk. Не скажу про дро другие соцсети, но vk позволяет производить куда-более точный поиск, чем fb/
А чего там у FB? Любой сайт, авторизовавший юзера с нужными правами, может читать его личные сообщения?
Получить право на доступ к личным сообщениям можно, да. Правда это право относится к так называемым «расширенным». То есть пользователь может подвтердить остальные (доступ к профилю, списку друзей), но указать, что слать и читать сообщения вам нельзя. В этом случае документация обязывает разработчика обработать такую ситуацию самостоятельно. Например, выдать сообщение: «Извините, у нашего приложения нет прав, поэтому Супер-Крутая-Фича не работает».
Кстати. ИМХО, это отличный выход для ВК. Основная проблема, насколько я понимаю, состоит в том, что пользователь бездумно соглашается. А как насчет такого варианта:
Защита «от дурака» на лицо: по умолчанию невнимательный пользователь просто не выдаст «расширенное право» приложению. Как вам такой вариант?
Кстати. ИМХО, это отличный выход для ВК. Основная проблема, насколько я понимаю, состоит в том, что пользователь бездумно соглашается. А как насчет такого варианта:
- Приложение просит права A, B, C из «обычных», а также D из «расширенных»
- Диалоговое окно поделено на две части. Обычные права приняты по умолчанию, расширенные — нет
- Чтобы приложение получило право на D, пользователь должен явно включить эту галку
- Если право выдано не было, приложение должно корректно обработать этот случай
Защита «от дурака» на лицо: по умолчанию невнимательный пользователь просто не выдаст «расширенное право» приложению. Как вам такой вариант?
Мне все-равно не нравится :( Но я API почти не занимаюсь, посмотрим…
Проблема в том, что «посмотрим» — это как-то очень закрыто звучит… =( О ходе «посмотрим» и результатах «посмотрим» трудно узнать из-вне. А API — это таки интерфейс для третьей стороны. Его просто нельзя разрабатывать за закрытыми дверями… Да и, на моей практике, обычно «посмотрим» приводит к «ну на фиг» =)
Короче, будет круто, если вы сможете подтолкнуть кого-то из отвечающих за судьбу API к диалогу. В любом случае, спасибо за успешный призыв. Думаю, это и было целью этого поста: обратить внимание кого-то из команды ВК на проблему.
Короче, будет круто, если вы сможете подтолкнуть кого-то из отвечающих за судьбу API к диалогу. В любом случае, спасибо за успешный призыв. Думаю, это и было целью этого поста: обратить внимание кого-то из команды ВК на проблему.
Да, скорее всего это «ну на фиг», увы. До тех пор, пока не назреет масштабно что-то реформировать.
В этом проблема маленькой команды — в данный момент (и на неопределенный период времени) все, допустим, четверо человек, которые имеют хоть какое-то отношение к решениям в общей схеме работе API весьма заняты своими весьма важными делами, из которых реально активно занимается API один. И из того, что внимание будет привлечено, не следует, что будет обещано что-то сделать в какие-то сроки…
В этом проблема маленькой команды — в данный момент (и на неопределенный период времени) все, допустим, четверо человек, которые имеют хоть какое-то отношение к решениям в общей схеме работе API весьма заняты своими весьма важными делами, из которых реально активно занимается API один. И из того, что внимание будет привлечено, не следует, что будет обещано что-то сделать в какие-то сроки…
Да я и не прошу сроков — это уж было бы как-то совсем… борзо. Я хочу простую штуку. Чтобы люди, «которые имеют хоть какое-то отношение к решениям в общей схеме работе API», подтвердили: «Да, мы поняли, в чем фишка, не считаем это чушью, будем думать об этом перед сном» =) Или высказали свое мнение. Если нечто подобное случится в этом посте, я буду считать задумку на 100% удавшейся.
Поймите, сейчас разработчики, вроде меня, гадают о двух вещах:
Это не есть гуд для API.
Поймите, сейчас разработчики, вроде меня, гадают о двух вещах:
- Причинах принятого когда-то решения и их актуальности на данный момент
- Дальнейшей судьбе этого механизма
Это не есть гуд для API.
Неужели у FB и с диалогом с разработчиками и выполнением пожеланий к API все хорошо? %)
У фейсбука нет дурацкого blank.html — он прекрасно возвращает назад, что сильно облегчает обработку того же токена. Так что нет, не в заботе дело совершенно. У каждого апи можно найти пару-тройку вот таких маразматических моментов. Ну хорошо, одноклассники целиком из них состоят — там маразмы смотрятся органично. Но тут-то в целом вполне вменяемое апи, но бац — костыль. Зачем? Для чего? Зебра ответить не может.
Возвращает назад веб-приложению токен с доступом к чтению личных сообщений?
Про чтение личных сообщений не знаю, но токен возвращает, да. Вконтакт ЛЮБОЙ токен на бланк.хтмл шлет — например, когда хочешь получить права на публикацию на стене.
Не любой, а с доступом к расширенным методам. У FB, похоже, нет расширенных методов в принципе — то есть он половину наших расширенных методов не дает вообще никому, а вторую записывает в обычные методы. Ну, про каждый конкретный метод тут можно говорить отдельно — надо ли его делать расширенным.
Про постинг на стене без уведомления владельца страницы — я думаю, что надо, незачем сайтам мне лить что-то без моего ведома на страницу. Постить с уведомлением владельца страницы (через бокс постинга) могут даже встроенные приложения, по идее и сайтам должно быть можно. Если нету, то можно сделать, наверное. Про остальные методы — ну, надо смотреть.
Про постинг на стене без уведомления владельца страницы — я думаю, что надо, незачем сайтам мне лить что-то без моего ведома на страницу. Постить с уведомлением владельца страницы (через бокс постинга) могут даже встроенные приложения, по идее и сайтам должно быть можно. Если нету, то можно сделать, наверное. Про остальные методы — ну, надо смотреть.
Да я не против получения токена — я против дурацкого блан.хтмл вместо возврата на сайт. Из-за этого приходится городить костыли.
Чего-то я не понял… blank.html сделан _только_ для токенов с десктоп-правами, для веб приложений их, считайте, не существует. Против чего вы собственно? %)
Все методы, которые разрешены для веб-приложений, делаются с токенами, которые выдаются через возврат на сайт, а не на blank.html, без костылей. Все токены, которые уходят на blank.html, не предполагается использовать в веб-приложениях, и уже описано почему — потому что это расширенные методы, только для desktop-приложений.
Все методы, которые разрешены для веб-приложений, делаются с токенами, которые выдаются через возврат на сайт, а не на blank.html, без костылей. Все токены, которые уходят на blank.html, не предполагается использовать в веб-приложениях, и уже описано почему — потому что это расширенные методы, только для desktop-приложений.
Ошибаетесь. ВКонтакт не отдает токен без бланк.хтмл, если запрашиваешь постинг на стену. У меня именно веб-приложение — плагин для кросспостинга статей из жумлы в соцсети, и для вконтакта пришлось городить костыли. Точнее, просто руками надо все вписывать, тогда как для фейсбука — просто 2 раза кнопу нажать.
Ну, как бы вы по сути и сказали с antanubis одно и то же, если учесть, что «постинг на стену» — это расширенный метод, доступный только для standalone-приложений.
Да, только в моем случае это НЕ десктопное приложение, и жутко неудобен этот бланк.хтмл. Впрочем, хорошо, что в принципе можно постить на стену — и на том спасибо. Маилру с одноклассниками до сих пор считают это жутким извращением, а одноклассники вообще все приложения воспринимают, как игры :-)
Хаха я помню когда апи было еще сырое-сырое, и приложение не требовало подтверждения пользователя на публикацию нового вопроса / мнения, можно было публиковать новые вопросы без ведома пользователя, т.е. как только он зашел в приложение, слать запросы на публикацию вопроса типа «А ты хочешь знать как читать чужие сообщения на сайте vkondakte.ru?». Но это еще во время массивного спама в вк.
В свое время, я столкнулся с проблемой получения эмайла от ВК, который в отличае от ФБ не хотел его отдавать. И как потом выяснилось получить, его все же можно. Для этого нужно личное обращение к администрации ВК. В сети даже есть пара сайтов которые запрашивают доступ к ВК на получение эмайла.
Типа реклама. Мы выкатили бета версию api. Может кому будет интересно. dev.professionali.ru/
Глядя на то, как поисковые системы сопротивляются SEOшникам, ВКшники сопротивляются SMMщикам.
Если разрешить вышеупомянутые функции и эмулировать комфортное мультиачье, SMM весьма удобно автоматизируется. То есть можно сделать программу, в которой весьма удобно будет работать SMMщику, она прям сильно облегчит ему жизнь.
А без этих функций сложно. Наверное, менеджмент ВК считает SMMщиков спамерами, всех без разбору. Да, это тупо и весьма печально, но до развития нормальной конкуренции вряд ли что-то серьезно изменится. Для того, чтобы идти навстречу каждой группе пользователей, нужна некоторая мотивация, которой у менеджеров ВК нет.
Если разрешить вышеупомянутые функции и эмулировать комфортное мультиачье, SMM весьма удобно автоматизируется. То есть можно сделать программу, в которой весьма удобно будет работать SMMщику, она прям сильно облегчит ему жизнь.
А без этих функций сложно. Наверное, менеджмент ВК считает SMMщиков спамерами, всех без разбору. Да, это тупо и весьма печально, но до развития нормальной конкуренции вряд ли что-то серьезно изменится. Для того, чтобы идти навстречу каждой группе пользователей, нужна некоторая мотивация, которой у менеджеров ВК нет.
Авторизовавшись с мобильного можно постить и писать сообщения с сервера
без ограничений (permission offline_access снимающий ограничение по ip)
Потому причина другая, а не как таковой запрет запросов к API с сервера.
без ограничений (permission offline_access снимающий ограничение по ip)
Потому причина другая, а не как таковой запрет запросов к API с сервера.
Когда писал приложение для ВА под андроид, просто взял токен с официального приложения и авторизовывался по паре логин/пароль, потом все же перешел на официальный метод получения токена. Может кому и пригодится такой вариант.
Я никак не могу придумать хоть один пример, зачем вам может понадобится чужая переписка? Не возможность писать пользователю, не возможность отвечать пользователю, а именно чужая, приватная переписка. Подскажите, пожалуйста.
А как вы разделите эти вещи? Если я могу писать пользователю и отвечать, значит я могу и переписку читать нашу, нет? Пример можно найти в комментариях выше. Я хочу отправлять сообщения пользователю. Но не могу.
А как вы разделите эти вещи?
Кажется, я понял почему ВК так сделал :).
Я вот не хочу, чтобы возможность читать мои сообщения была в принципе, отключенная, скрытая, включенная или отключенная галочка, короче любой способ — как только такая возможность появится, ее будут пихать куда не лень. А вот если вы придумаете, как разделить на «чужие» и «точно, абсолютно точно мои сообщения», может разработчики ВК и пойдут навстречу.
Очень стараюсь придумать, как видите ^_^ А чем вас не устраивает этот вариант? В этом случае, если вы никому не хотите выдавать право, просто не делайте этого. Игнорируйте и все. По умолчанию все выключено же…
P.S. Я предлагаю и вам подумать над проблемой, вдруг что-то придет в голову =) Коллективный разум всегда сильнее одиночного.
P.S. Я предлагаю и вам подумать над проблемой, вдруг что-то придет в голову =) Коллективный разум всегда сильнее одиночного.
Допустим, я хочу получать сообщения от вашего движка, но не хочу чтобы оно лезло не в свои или отправляло от моего имени. Сейчас возможности такой тонкой настройки вроде нет ни в одном апи. Подозреваю, что введение потребует очень большой переработки подсистемы управления доступом в целом.
Я не хочу, чтобы возможность читать чужые сообщение для веб приложений была в принципе. Все ошибаются, это раз, и не ровен час нужный сайт запросит доступ до сообщений, а иначе никак — и станет на одного пользователя меньше. Ему все равно, а для меня он нужен.
Как по мне, было бы замечатально входить от имены группы, как это сделано на фб (там не полноценный вход, но принцип понятен), и только для групп, и ни для кого больше, позволить доступ до своих сообщений, возможность их принимать и отправлять. Простая умова — пользователю расширенный метод, группе — обычний. Тогда пользователи ни под каким предлогом не смогут дать доступ к своим сообщениям, зато группы получат необходимый интерфейс, плюс к тому это деловая, но не интимная переписка, как-то легче со страхом ее потерять. Ну и ко всему прочему группа — это как раз магазины, сообщества, даже на уровне абстракций в мозгу четкое разделение.
Как по мне, было бы замечатально входить от имены группы, как это сделано на фб (там не полноценный вход, но принцип понятен), и только для групп, и ни для кого больше, позволить доступ до своих сообщений, возможность их принимать и отправлять. Простая умова — пользователю расширенный метод, группе — обычний. Тогда пользователи ни под каким предлогом не смогут дать доступ к своим сообщениям, зато группы получат необходимый интерфейс, плюс к тому это деловая, но не интимная переписка, как-то легче со страхом ее потерять. Ну и ко всему прочему группа — это как раз магазины, сообщества, даже на уровне абстракций в мозгу четкое разделение.
Помимо переписки, в методах для desktop ещё 100500 нужных вещей.
Это да. Но обсуждение как-то само собой скатилось к личной переписке. Будет круто, если вы приведете какой-то другой сценарий разумного применения расширенных методов в веб-приложениях. Мне пока в голову приходит, например, удивительный факт: загружать фотографии через API веб-приложениям можно, а вот удалять — нет.
Если подумать, то не так уж он и удивителен. Удаление — деструктивное и, вроде, необратимое действие. Если приложение напихает кучу картинок, то их можно удалить и ничего не изменится по сути, но если приложение удалит все фотографии пользователя, то назад их может быть вернуть невозможно, а это может быть единственный экземпляр, очень важный для пользователя.
А так я могу порнографические фотки начать грузить в альбомы пользователя! %) У любой предоставленной возможности есть темная сторона.
Ну, а если серьезно, то это ограничение уничтожает любые шансы создать, например, альтернативную галлерею фотографий в ВК или, скажем, синхронизировать папку в Dropbox с альбомами ВК, чем я занимался. В итоге пришлось реализовывать «удаление» через перемещение в специальный альбом.
Ну, а если серьезно, то это ограничение уничтожает любые шансы создать, например, альтернативную галлерею фотографий в ВК или, скажем, синхронизировать папку в Dropbox с альбомами ВК, чем я занимался. В итоге пришлось реализовывать «удаление» через перемещение в специальный альбом.
Немного саморекламы, надеюсь мой компьютер не умрёт. Для одного из своих сайтов за ночь наваял класс, который умеет постить на стенку группы (от лица вашего пользователя через ваше приложение)
В принципе, если доковырять, можно использовать любой метод апи, класс делает самое главное — авторизуется. Кому интересно, прошу по ссылке
http://jcover.ru/vkontakte-sozdanie-zapisi-na-stene-gruppyi-so-svoego-sayta/
В принципе, если доковырять, можно использовать любой метод апи, класс делает самое главное — авторизуется. Кому интересно, прошу по ссылке
http://jcover.ru/vkontakte-sozdanie-zapisi-na-stene-gruppyi-so-svoego-sayta/
Апи вконтакта всегда славилось своей костыльностью. Скольких нервов стоила только настройка авторизации по OAuth2, которая так и не смогла быть полноценно реализована из-за того, что у вк нет страницы oauth/me, которая позволяла бы идентифицировать пользователя по токену.
Посмотрите, пожалуйста, какие есть ещё способы вызывать расширенные методы из Web-приложений: habrahabr.ru/post/179953/#comment_6266207, habrahabr.ru/post/179953/#comment_6265353 (тут говорится про Web-компонент), на случай, если в предыдущих комментах вы их не заметили.
Т. е. можно как-то имитировать запрос к oauth.vk.com/authorize, потом как-то поймать URL, на который перенаправили. На крайняк, просто виртуализировать браузер на стороне клиента или сервера. Т. е. просто создать виртуальный браузер, от него послать запрос на authorize и посмотреть, на какой URL он будет перенаправлен.
Вообще, есть чел, которой виртуализировал целую операционную систему на стороне клиента в Web-приложении: bellard.org/jslinux.
Если даже целую ОС можно виртуализировать на стороне клиента, то почему нельзя виртуализировать браузер в браузере? Можно, конечно. И из виртуального браузера сделать authorize и достать токен. Поэтому, говорю вам: обойти указанную проблему можно. Да, будут костыли. Но можно. И не надо даже хаков, указанных тут: habrahabr.ru/post/179953/#comment_6265921.
Итак, все технические проблемы тут можно обойти. Единственная проблема, которая тут есть в том, что использовать расширенное API из Web-приложений запрещено правилами Контакта, и потому нечестно. :) Если бы я писал Web-приложение с раширенным API, это единственное, что меня бы волновало, а не технические проблемы.
Ответьте мне пожалуйста, kimrgrey
Т. е. можно как-то имитировать запрос к oauth.vk.com/authorize, потом как-то поймать URL, на который перенаправили. На крайняк, просто виртуализировать браузер на стороне клиента или сервера. Т. е. просто создать виртуальный браузер, от него послать запрос на authorize и посмотреть, на какой URL он будет перенаправлен.
Вообще, есть чел, которой виртуализировал целую операционную систему на стороне клиента в Web-приложении: bellard.org/jslinux.
Если даже целую ОС можно виртуализировать на стороне клиента, то почему нельзя виртуализировать браузер в браузере? Можно, конечно. И из виртуального браузера сделать authorize и достать токен. Поэтому, говорю вам: обойти указанную проблему можно. Да, будут костыли. Но можно. И не надо даже хаков, указанных тут: habrahabr.ru/post/179953/#comment_6265921.
Итак, все технические проблемы тут можно обойти. Единственная проблема, которая тут есть в том, что использовать расширенное API из Web-приложений запрещено правилами Контакта, и потому нечестно. :) Если бы я писал Web-приложение с раширенным API, это единственное, что меня бы волновало, а не технические проблемы.
Ответьте мне пожалуйста, kimrgrey
Можно виртуализировать браузер в браузере, а в нем, в свою очередь, запустить браузер =) Было бы желание. С этим я не спорю. Но есть два нюанса.
Когда я писал пост, моей целью было не найти способ изящно прогнуться под существующий порядок вещей, а изменить его, указав авторам API на его недостатки. Получилось ли из этого что-то? Покажут время и change log =)
- Вы бесцеремонно нарушите прямой запрет веб-приложениям использовать расширенные методы API и оказываетесь вне закона.
- Все вышеперечисленные изыски вам придется поддерживать. Если вы пользуетесь подобного рода трюками, никто на стороне ВК не гарантирует вам, что завтра это будет работать точно также, как сегодня. В случае монитизируемого приложения это может вам дорого встать, в прямом смысле этих слов.
Когда я писал пост, моей целью было не найти способ изящно прогнуться под существующий порядок вещей, а изменить его, указав авторам API на его недостатки. Получилось ли из этого что-то? Покажут время и change log =)
1. А почему тогда вы написали этот коммент: habrahabr.ru/post/179953/#comment_6265961? Я тоже согласен, с тем, что нарушать правила нельзя. Просто раз уж вы всё-таки подумываете о том, чтобы их нарушить (заставляя юзера копировать какие-то строчки в адресную строку), то не лучше ли тогда сделать это каким-нибудь другим способом, не доставляя юзеру хлопот.
Если пост ни к чему не приведет, то мне это видится более или менее приемлимым способом. Если полазить по комментариям, его же предлагали и ребята из VK, как обходной маневр. Он прост, а потому надежен и вряд ли подведет, даже если что-то в API изменится. Пока оно работает по принципам OAuth, все будет ок. Хотя я в конечном итоге больше склоняюсь к переносу части функций приложения на десктоп, благо для меня это возможно и опыт позволяет.
А чем отличается десктоп от сервера (не сайта, а именно сервера)? Пишем десктопную программу, которая слушает заданный порт, имеет доступ до базы для внутренней авторизации, и работает с ВК как обычная программа на обычном телефоне.
Как-то у вас все сложно… =) Где слушает порт? До какой базы имеет доступ? Откуда тут телефоны, если речь о десктопе? o_O
В моем случае управляющая часть приложения просто переместится в standalone-приложение на Qt, поставляемое конечному пользователю. Авторизация таких приложений происходит через встраиваемый в них браузер. В случае с Qt он поставляется с WebKit. Ну а дальше по описанному в статье и предполагаемому API сценарию. Чтобы получить токен с расширенными правами, необходимо указать в качестве callback-адреса специальный URL, затем отловить событие onRedirect от WebKit и получить все необходимые данные: токен, uid пользователя, срок жизни.
В моем случае управляющая часть приложения просто переместится в standalone-приложение на Qt, поставляемое конечному пользователю. Авторизация таких приложений происходит через встраиваемый в них браузер. В случае с Qt он поставляется с WebKit. Ну а дальше по описанному в статье и предполагаемому API сценарию. Чтобы получить токен с расширенными правами, необходимо указать в качестве callback-адреса специальный URL, затем отловить событие onRedirect от WebKit и получить все необходимые данные: токен, uid пользователя, срок жизни.
Это тот случай, когда сначала говоришь, а потом думаешь :). Я в первую секунду подумал, что сервер по сути тот же десктоп, и он может запустить приложение, которое будет работать с ВК. Но вот о том, что надо еще кое-что от пользователя, я забыл.
Рад, что смог вам помочь =) Ниже тредом чуть более развернутое описание проблемы.
Я не понимаю, какая проблема в этом посте: habrahabr.ru/post/179953/#comment_6268855?
Можно же просто сделать приложение Standalone-приложением и запустить его на стороне сервера, и оттуда отправить.
Давайте разберёмся: есть интернет-магазин, а есть юзер, то есть клиент, который покупает что-то в этом магазине.
Так вот, ясно, что заставлять юзера устанавливать себе на комп некое Standalone-приложение недопустимо. Юзер просто свалит, если узнает, о том, что ему нужно это сделать.
Но это и не требуется.
Ведь в данном случае нужно послать сообщение не от лица юзера, а от лица интернет-магазина.
То есть не нужно автоматизировать отправку сообщения юзером, а нужно автоматизировать отправку сообщения интернет-магазином.
То есть нужно поставить Standalone-приложение, условно говоря, на комп интернет-магазину (т. е. на сервер интернет-магазина), а не на комп юзеру.
А уж серверами интернет-магазина занимаются сисадмины этого самого интернет-магазина. А они-то уж не отпугнуться от осознавания того, что им нужно поставить некое Standalone-приложение. Они хорошо разбираются в IT, в отличие от (скорее всего) юзера.
P. S. IDMan в комменте выше, как я понял, тоже имеет в виду это: habrahabr.ru/post/179953/#comment_6274667
P. P. S. И это я пытался сказать здесь: habrahabr.ru/post/179953/#comment_6266593. Мне кажется, портануть приложение на разные сервера не так уж сложно. Да и вообще, допустим, есть просто какой-нибудь один чел, и он хочет это сделать на своём сервере (тот же интернет-магазин, например). Сделает? Конечно, сделает. У него нет нужды портировать приложение на разные сервера, нужно только заставить его работать на одном.
Можно же просто сделать приложение Standalone-приложением и запустить его на стороне сервера, и оттуда отправить.
Давайте разберёмся: есть интернет-магазин, а есть юзер, то есть клиент, который покупает что-то в этом магазине.
Так вот, ясно, что заставлять юзера устанавливать себе на комп некое Standalone-приложение недопустимо. Юзер просто свалит, если узнает, о том, что ему нужно это сделать.
Но это и не требуется.
Ведь в данном случае нужно послать сообщение не от лица юзера, а от лица интернет-магазина.
То есть не нужно автоматизировать отправку сообщения юзером, а нужно автоматизировать отправку сообщения интернет-магазином.
То есть нужно поставить Standalone-приложение, условно говоря, на комп интернет-магазину (т. е. на сервер интернет-магазина), а не на комп юзеру.
А уж серверами интернет-магазина занимаются сисадмины этого самого интернет-магазина. А они-то уж не отпугнуться от осознавания того, что им нужно поставить некое Standalone-приложение. Они хорошо разбираются в IT, в отличие от (скорее всего) юзера.
P. S. IDMan в комменте выше, как я понял, тоже имеет в виду это: habrahabr.ru/post/179953/#comment_6274667
P. P. S. И это я пытался сказать здесь: habrahabr.ru/post/179953/#comment_6266593. Мне кажется, портануть приложение на разные сервера не так уж сложно. Да и вообще, допустим, есть просто какой-нибудь один чел, и он хочет это сделать на своём сервере (тот же интернет-магазин, например). Сделает? Конечно, сделает. У него нет нужды портировать приложение на разные сервера, нужно только заставить его работать на одном.
- У вас есть движок для создания интернет-магазинов — Spree. Вы пишите к нему расширение, которое я описал в упомянутом вами комментарии. В терминах RoR, вы создаете гем. Как вы предлагаете поставлять ваше standalone-приложение? На чем вы его напишите?
- Допустим, придумали как. Напишите в документации, что очень нужно его скачать и запустить. Так оно еще и UI, очевидно, должно обладать, чтобы браузер открыть пользователю и дать возможность пройти авторизацию и подтвердить права на токен, верно? Часто вы на линуксовых VPS иксы видели?
safinaskar, как и я, имел ввиду авторизацию магазина, пользователю мы будем отправлять от имени аккаунта магазина. То есть, никаких приложений пользователю грузить не требуется — конечно, если нам нужно написать ему, и прочитать ответ, а не играть в ФСБ.
Мне казалось, мы с вами только что все поняли и разобрались, что к чему =) Или нет?
Чтобы магазин мог что-то кому-то отправить через ВК, ему нужен токен, принадлежащий тому аккаунту, от имени которого он будет действовать. Являясь веб-приложением, он его получить не может.
>> нужно поставить Standalone-приложение, условно говоря, на комп интернет-магазину (т. е. на сервер интернет-магазина)
Как видим, safinaskar предлагает поставить отдельное приложение прямо на сервер. Я написал, почему этого сделать не получится.
Чтобы магазин мог что-то кому-то отправить через ВК, ему нужен токен, принадлежащий тому аккаунту, от имени которого он будет действовать. Являясь веб-приложением, он его получить не может.
>> нужно поставить Standalone-приложение, условно говоря, на комп интернет-магазину (т. е. на сервер интернет-магазина)
Как видим, safinaskar предлагает поставить отдельное приложение прямо на сервер. Я написал, почему этого сделать не получится.
Мы разобрались из запросами прав пользователя. Тут да, вопросов нет, я ошибся. Но если вам нужно действовать от имени своего аккаунта, скрипт на сервера может быть тем самим десктоп приложением. Короче, я попробую сделать черновик на питоне, к примеру, и если получится работать сайтом через него с ВК, напишу о результатах. А нет, так и суда на нет нет.
>> скрипт на сервера может быть тем самим десктоп приложением
Скрипт на сервере не может быть десктоп-приложением, потому что для получения токена ему потребуется UI, который не будет работать без X-ов, которых на сервере нет. Это уж не говоря о том, что конечный пользователь доступа к приложению не получит. Если же вы раздобудите токен иным путем (попросите пользователя скопировать его вам откуда-либо), то им может воспользоваться и веб-приложение, не нужно будет ничего городить.
Скрипт на сервере не может быть десктоп-приложением, потому что для получения токена ему потребуется UI, который не будет работать без X-ов, которых на сервере нет. Это уж не говоря о том, что конечный пользователь доступа к приложению не получит. Если же вы раздобудите токен иным путем (попросите пользователя скопировать его вам откуда-либо), то им может воспользоваться и веб-приложение, не нужно будет ничего городить.
Скрипт на сервере не может быть десктоп-приложением, потому что для получения токена ему потребуется UI, который не будет работать без X-ов, которых на сервере нет.
Заблуждение. Я неоднократно эмулировал скриптами работу браузера в подобных случаях. Сайт не может знать обращается к нему скрипт или браузер. Единственное значимое препятствие — различные капчи, но и то решаемое с помощью «OCR онлайн-сервисов с элементами интеллекта». Единственное — требуется постоянное слежение за html, отдаваемым сайтом, что может быть затруднительно, если владельцы сайта активно противодействуют эмуляции браузеров, вернее живых пользователей, и будет постоянно требоваться оперативный реверс-инженеринг их придумок.
Господа, По кругу однако ходим… Вам потребуется взаимодействовать с пользователем, чтобы он подтвердил ваше право на токен. Можно эмулировать браузер и пронажимать все кнопки на манер тестирующих скриптов, но это хак, костыль и ужас, летящий на крыльях ночи. Можно найти миллиард и один подобный хак. Но в статье явно обозначена моя позиция по поводу всех этих ухищрений:
Я решил попытаться что-то изменить. Проблема состоит в том, что API — это прежде всего интерфейс, предназначенный для сторонних разработчиков. Им пользуюсь не только я, но и тысячи других программистов, ежедневно клепающих всякие хаки и применяющих грязные трюки, чтобы решить очень простую и логичную задачу, принеся счастье и улыбки в дом конечного пользователя. Логично предположить, что эти самые разработчики должны иметь возможность как-то влиять на эволюцию инструмента, которым им предлагается пользоваться. Имеющееся сейчас разграничение на обычные и расширенные методы создает ощущение… ну… как от кофейного автомата, который почему-то не умеет выдавать сдачу: вроде кофе и можно купить, но придется всем отделом мелочь собирать.
Я исхожу из предположения, что пользователь и является владельцем сервера и раз установил на нем веб-приложение (серверное приложение), то способен и установить «эмулятор браузера». Полная аналогия с десктоп и мобильными приложениями. Хотя согласен, что хак и было бы неплохо тому, кто устанавливает серверное приложение у себя на сервере добавить и возможности обходится без хаков, а иметь такой же доступ к API для совершения действий со своего (владельца сервера) аккаунта, какой предоставляется устанавливающим десктоп или мобильные приложения, без ограничений и преференций (вводят логин и пароль в десктопных приложениях, пускай водят и в серверных), а по хорошему все функции «нативного» веб-интерфейса должны быть доступны любому пользователю, устанавливающему приложение (серверное, десктопное или мобильное — без разницы) и доверившему приложению управление своим аккаунтом.
Но в случае серверных веб-приложений обычно речь идёт о другом. О доверии своего аккаунта владельцам другого аккаунта. Не разработчикам приложения, а тем, кто его установил. Не, грубо говоря, о добавлении владельца чужого аккаунта к себе «в друзья», а о передаче ему каких-то прав по управлению аккаунтом. И тут возникает масса проблем этического и правового характера, технические на их плане отступают.
Но в случае серверных веб-приложений обычно речь идёт о другом. О доверии своего аккаунта владельцам другого аккаунта. Не разработчикам приложения, а тем, кто его установил. Не, грубо говоря, о добавлении владельца чужого аккаунта к себе «в друзья», а о передаче ему каких-то прав по управлению аккаунтом. И тут возникает масса проблем этического и правового характера, технические на их плане отступают.
удалено
>>> Если пост ни к чему не приведет, то мне это видится более или менее приемлимым способом.
Т. е. самый приемлимый способ для вас: заставить юзера копировать что-то в строку браузера? Это ХУДШИЙ из всех способов, т. к. он имеет самый низкий user experience :) Большинство юзеров просто не будут вам доверять после этого. Хотя, опять-таки, смотря какие у вас там юзеры. Особенно не будут доверять после этой фразы на oauth.vk.com/blank.html. Гораздо лучше воспользоваться любым другим способом, виртуализировать там браузер в браузере и др.
P. S. Наконец прочитал про ваш проект тут: habrahabr.ru/post/179953/#comment_6268961. Ну так вот, какие есть варианты:
1. Просить юзера (здесь уже под юзером я имею в виду сотрудника интернет-магазина, например) вводить токен
2. Запускать Standalone-приложение на компе юзера
3. Запускать браузер в браузере (опять-таки, на компе юзера)
4. Запускать браузер на сервере, ну или делать Standalone-приложение на сервере. Иными словами, встроить нужную функциональность в серверную часть движка
С технической точки зрения любой из вариантов реализуем.
«2» плох тем, что юзерам надо ставить что-то дополнительное на свои компы. «1» — тем, что мы подвигаем юзера к странным действиям.
Остальные («3» и «4») идеальные. Вы говорите, что будете действовать по варианту «2», если не удастся наладить контакт с представителями Вконтакте. Так вот, зачем? Если есть варианты «3» и «4», которые лучше, чем «2», и при этом ничем не хуже. Если их удастся легко реализовать, то это вообще здорово.
А по поводу честности, я теперь уже даже не уверен, какие из этих методов нарушают правила Контакта, а какие — нет. С одной стороны, в любом случае у вас Web-приложение (наверное, даже если код исполняется на стороне сервера). Поэтому все варианты нарушают правила Контакта. С другой стороны, вы не пишите приложение, предназначенное для огромного количества людей в интернете, а пишите приложение, запускаемое на сервере, к которому будут подключаться сотрудники той же фирмы, которой принадлежит сервер (я правильно понял?). Поэтому, возможно, для вас нужно сделать исключение. Вот уже, видите, один сотрудник Вконтакта говорит, что в принципе никакого нарушения правил нет: habrahabr.ru/post/179953/#comment_6268925. Так что, если вас волнует вопрос честности, то сделайте запрос в Вконтакт, объяснив ситуацию, как вы это сделали в этом посте: habrahabr.ru/post/179953/#comment_6268961, и спросите, какие из указанных способов будут для вас честными, а какие — нет. Упор делаете на то, что это Web-приложение, предназначенное для сотрудников той же фирмы, где стоит сервер, то есть это тупо внутренняя клиент-серверная программа (как я понял).
Т. е. самый приемлимый способ для вас: заставить юзера копировать что-то в строку браузера? Это ХУДШИЙ из всех способов, т. к. он имеет самый низкий user experience :) Большинство юзеров просто не будут вам доверять после этого. Хотя, опять-таки, смотря какие у вас там юзеры. Особенно не будут доверять после этой фразы на oauth.vk.com/blank.html. Гораздо лучше воспользоваться любым другим способом, виртуализировать там браузер в браузере и др.
P. S. Наконец прочитал про ваш проект тут: habrahabr.ru/post/179953/#comment_6268961. Ну так вот, какие есть варианты:
1. Просить юзера (здесь уже под юзером я имею в виду сотрудника интернет-магазина, например) вводить токен
2. Запускать Standalone-приложение на компе юзера
3. Запускать браузер в браузере (опять-таки, на компе юзера)
4. Запускать браузер на сервере, ну или делать Standalone-приложение на сервере. Иными словами, встроить нужную функциональность в серверную часть движка
С технической точки зрения любой из вариантов реализуем.
«2» плох тем, что юзерам надо ставить что-то дополнительное на свои компы. «1» — тем, что мы подвигаем юзера к странным действиям.
Остальные («3» и «4») идеальные. Вы говорите, что будете действовать по варианту «2», если не удастся наладить контакт с представителями Вконтакте. Так вот, зачем? Если есть варианты «3» и «4», которые лучше, чем «2», и при этом ничем не хуже. Если их удастся легко реализовать, то это вообще здорово.
А по поводу честности, я теперь уже даже не уверен, какие из этих методов нарушают правила Контакта, а какие — нет. С одной стороны, в любом случае у вас Web-приложение (наверное, даже если код исполняется на стороне сервера). Поэтому все варианты нарушают правила Контакта. С другой стороны, вы не пишите приложение, предназначенное для огромного количества людей в интернете, а пишите приложение, запускаемое на сервере, к которому будут подключаться сотрудники той же фирмы, которой принадлежит сервер (я правильно понял?). Поэтому, возможно, для вас нужно сделать исключение. Вот уже, видите, один сотрудник Вконтакта говорит, что в принципе никакого нарушения правил нет: habrahabr.ru/post/179953/#comment_6268925. Так что, если вас волнует вопрос честности, то сделайте запрос в Вконтакт, объяснив ситуацию, как вы это сделали в этом посте: habrahabr.ru/post/179953/#comment_6268961, и спросите, какие из указанных способов будут для вас честными, а какие — нет. Упор делаете на то, что это Web-приложение, предназначенное для сотрудников той же фирмы, где стоит сервер, то есть это тупо внутренняя клиент-серверная программа (как я понял).
>> Т. е. самый приемлимый способ для вас: заставить юзера копировать что-то в строку браузера?
>> Наконец прочитал про ваш проект
Это один из примеров, показывающих случай, где личные сообщения могли бы быть очень полезны. В данном конкретном варианте просить скопировать что-то в настройки админки вполне допустимо, ибо, как вы верно заметили выше, речь идет о достаточно квалифицированных людях — администраторах интернет-магазина.
>> делать Standalone-приложение на сервере. Иными словами, встроить нужную функциональность в серверную часть движка
Это по просту не имеет смысла, так как, я уже говорил, с вероятностью 98% на сервере нет X-ов и вы не сможете предоставить пользователю возможность подтвердить право вашего приложения на получение токена.
Итого. Изящного и простого решения просто нет. Все возможные хаки можно найти в комментариях. Для расширения Spree я предпочту копирование URL. Для основного проекта, который толкнул меня к написанию статьи, решением будет поставка отдельного десктопного приложения. Там это допустимо, просто и естественно.
>> Наконец прочитал про ваш проект
Это один из примеров, показывающих случай, где личные сообщения могли бы быть очень полезны. В данном конкретном варианте просить скопировать что-то в настройки админки вполне допустимо, ибо, как вы верно заметили выше, речь идет о достаточно квалифицированных людях — администраторах интернет-магазина.
>> делать Standalone-приложение на сервере. Иными словами, встроить нужную функциональность в серверную часть движка
Это по просту не имеет смысла, так как, я уже говорил, с вероятностью 98% на сервере нет X-ов и вы не сможете предоставить пользователю возможность подтвердить право вашего приложения на получение токена.
Итого. Изящного и простого решения просто нет. Все возможные хаки можно найти в комментариях. Для расширения Spree я предпочту копирование URL. Для основного проекта, который толкнул меня к написанию статьи, решением будет поставка отдельного десктопного приложения. Там это допустимо, просто и естественно.
На сервере можно залогиниться так же, как и на телефоне. (Именно это имел в виду IDMan тут: habrahabr.ru/post/179953/#comment_6274667, когда говорил про телефон.) Насколько я понимаю, для этого нужен логин и пароль.
Вот когда я на андроиде логинюсь Вконтакт при помощи мобильного приложения, оно лишь спрашивает логин и пароль и ничего больше. И логинится. Может быть, оно создаёт некий виртуальный браузер, может, нет. Но оно не выдаёт никаких дополнительных окошек с вопросами типа «Приложение лалала запрашивает доступ к вашему аккаунту».
Т. е. делаем так: сотрудник магазина забивает логин и пароль в браузер (как я понял, логин и пароль), они передаются на сервер, сервер с их помощью логинится (UI и иксы тут не нужны, возможно, понадобится создать виртуальный браузер, но он не будет требовать взаимодействия с пользователем) и готово.
Вот когда я на андроиде логинюсь Вконтакт при помощи мобильного приложения, оно лишь спрашивает логин и пароль и ничего больше. И логинится. Может быть, оно создаёт некий виртуальный браузер, может, нет. Но оно не выдаёт никаких дополнительных окошек с вопросами типа «Приложение лалала запрашивает доступ к вашему аккаунту».
Т. е. делаем так: сотрудник магазина забивает логин и пароль в браузер (как я понял, логин и пароль), они передаются на сервер, сервер с их помощью логинится (UI и иксы тут не нужны, возможно, понадобится создать виртуальный браузер, но он не будет требовать взаимодействия с пользователем) и готово.
Вы говорите о прямой авторизации пользователя, которая работает в обход OAuth. Этот тип авторизации доступен только по согласованию с администрацией ВК для доверенных приложений. Просто так вам никто этого сделать не даст.
Поймите, вы сосредоточились на решении конкретной задачи, которая является лишь следствием более серьезной вещи — ограниченности, свойственной VK API для веб-приложений. Этому и посвящены статья и все дальнейшее обсуждение. Ведь даже если вы добьетесь прямой авторизации в данном конретном случае, — что вряд ли, ну да черт с ним, — когда вы будете писать любой другой сервис, который поставляется не админам, а самым обычным пользователям (скажем, галлерея фотографий с возможностью их загружать, просматривать и удалять из ВК), вы не сможете применить прямую авторизацию. Просто потому что ни один разумный пользователь не даст вам пароль от своего аккаунта, так как вы получите полную свободу действий, в то время как токен имеет вполне понятные ограничения.
Поймите, вы сосредоточились на решении конкретной задачи, которая является лишь следствием более серьезной вещи — ограниченности, свойственной VK API для веб-приложений. Этому и посвящены статья и все дальнейшее обсуждение. Ведь даже если вы добьетесь прямой авторизации в данном конретном случае, — что вряд ли, ну да черт с ним, — когда вы будете писать любой другой сервис, который поставляется не админам, а самым обычным пользователям (скажем, галлерея фотографий с возможностью их загружать, просматривать и удалять из ВК), вы не сможете применить прямую авторизацию. Просто потому что ни один разумный пользователь не даст вам пароль от своего аккаунта, так как вы получите полную свободу действий, в то время как токен имеет вполне понятные ограничения.
«Этот тип авторизации доступен только по согласованию с администрацией ВК для доверенных приложений.» — да. Свяжитесь с админами VK и согласуйте. Это будет более right way решение, чем заставлять людей копировать некий код в строки браузера. (Хотя, в принципе, необязательно :) В принципе, копировать URL'ы — более-менее нормальное решение.)
«Поймите, вы сосредоточились на решении конкретной задачи» — дык в этом-то и всё дело, что я вам пытаюсь помочь в решении этой вашей конкретной задачи (она ведь реально перед вами стоит, да?). А по поводу общей проблемы (расширенное API работает только для Mob/Stan) я с вами согласен, что проблема есть. Но вряд ли мы сможем щас что-то добиться.
«Поймите, вы сосредоточились на решении конкретной задачи» — дык в этом-то и всё дело, что я вам пытаюсь помочь в решении этой вашей конкретной задачи (она ведь реально перед вами стоит, да?). А по поводу общей проблемы (расширенное API работает только для Mob/Stan) я с вами согласен, что проблема есть. Но вряд ли мы сможем щас что-то добиться.
Вот тут про это рассказано: vk.com/dev/auth_direct.
Правило Хабра #429: если у вас возникла проблема, в связи с которой вы написали пост на Хабре, то опишите проблему в самом посте.
Я имею в виду, что habrahabr.ru/post/179953/#comment_6274801 надо было сразу писать в тексте, а то будет просто много комментов, уводящих в сторону
Я имею в виду, что habrahabr.ru/post/179953/#comment_6274801 надо было сразу писать в тексте, а то будет просто много комментов, уводящих в сторону
Что-то изменилось с тех пор? Wall все так же не выдается. Какие есть пути решения через семь лет после данного поста?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Об одном недостатке VK API вслух