VK API: как проверить, что access_token соответствует uid при минимальных разрешениях?
Всем привет,
Есть следующий сценарий: клиент и сервер написанные на ява.
Клиент проходит аутенфикация ВКонтакте и получается uid и access_token, которые посылает на сервер.
Дальше сервер делает пробный запрос к API с полученным access_token и uid и получает имя пользователя.
Но как удостовериться, что access_token соответствуюет фиксированному uid? При этом я не хочу пугать пользователя, запрашивая разрешения на извлечение таких данных, где возможно это соответствие и будет проверяться.
Например, клиент пройдя аутенфикацию может послать на сервер свой access_token и не свой uid. Но поскольку access_token будет правильный, то и запросы будут нормально
И еще мне сказали, что выданный access_token может зависить от IP, его получившего. Правда или нет, не знаем, не может найти подтверждения или опровержения.
> И еще мне сказали, что выданный access_token может зависить от IP, его получившего. Правда или нет, не знаем, не может найти подтверждения или опровержения.
Это оказалось не правдой.
Надеюсь еще не поздно написать ответ, но Вы можете проверить id пользователя через полученный access_token. Для этого нужно выполнить метод users.get, передав ему полученный access_token (https://api.vk.com/method/users.get?access_token=ТОКЕН).
«Обратите внимание, что обращаться к API при использовании типа «Standalone-приложение» требуется с клиента, а не со стороннего сервера. Использовать клиентский access_token на стороннем сервере для запросов к API запрещено» – https://vk.com/dev/standalone
Как быть?
Не совсем понял вопрос, но соответствие uid проверяется по auth_key, который должен быть равен md5(viewer_id(uid)+'_'+app_id+'_'+app_secret_key),
где viewer_id это айди пользователя, просматривающего страницу, app_id это айди приложения и auth_secret_key это секретный ключ приложения. Хэш данного выражения должен быть равен параметру auth_key, в противном случае указанный пользователь не соответствует реальному.
То он сработает даже и для другого uid2, при правильном access_token.
Про минимальные разрешения:
Думаю запрос photos.getAlbums не будет работать если указать чужой uid, но чтобы иметь возможность выполнить такой запрос, надо чтобы в самом начале пользователь разрешил приложению доступ к своим фотографиям и альбомам, а это очень обязывающий шаг.
Про вашу формулу не понял viewer_id(uid) — это функция или произведение двух чисел? И можно ссылка на первоисточник?
Я полагаю, damirazo написал о проверке на то, является ли пользователь с отправленным вам uid (или, как написано тут, viewer_id) тем, за кого себя выдаёт. Вы должны на сервере проверить равенство auth_key (вы, мне кажется, путаете его с access_token) и md5(api_id + '_' + viewer_id + '_' + api_secret). Если они равны, то пользователь с отправленным uid тот, за кого себя выдаёт. access_token — ваш ключ, с помощью которого вы будете получать доступ к API ВКонтакте.
Если вы хотите использовать, например, users.get, то вы должны отправить:
Где %идентификатор% — идентификатор пользователя, о котором вы хотите узнать какую-то информацию (в случае нашего запроса — uid, first_name и last_name т.к. они стандартные). %ключ% — это и есть access_token, полученный при авторизации клиента.
Насколько понимаю, auth_key и access_token — разные штуки.
Пример access_token: e7618f33b73b5467e7bede4db4e35cdb38ee76de76ca46418ea02e9112efef675ca4623
Пример auth_key: b02333242aab4ca1504afb31087e6f2a по формуле md5
А где мне взять auth_key с которым надо сравнивать?
«Этот параметр приходит, если в приложении включена система платежей (во вкладке Платежи при редактировании приложения). „
У меня, в тестовых приложениях, данный параметр (auth_key) доступен. Но для начала надо активировать свое приложение, система платежей не обязательна (вкладка «настройки», параметр «приложение включено и видно всем»).
Чтобы приложение сервер мог быть уверен, что пользователь тот за кого себя выдает.
На клиенте вы не вводите логин и пароль, а нажимаете кнопку залогинить вконтакте. Клиент получает userId и access_token (кстати может быть написан другой стороной), и отдает их серверу. Тот проверят, если сошлись, то пускает, а если нет, то нет.
Забавно, access_token уже давно получен.
Задача в том, что имея на руках uid и access_token (валидный) и запроса к API проверить был получен этот access_token пользователем с этим uid.
Средний
