Проблемы и заявки об ошибках Wargaming Public API
Дата: 30.10.2013 15:36:23
Цитата HTTP/1.1 302 Found
Server: nginx
Date: Wed, 30 Oct 2013 12:15:48 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=30
X-Powered-By: PHP/5.3.27
X-Content-Type-Options: nosniff
Location: https://api.worldoft...application_id=<�мой_апп_ID>&redirect_uri=http://test.com/callback.php
Content-Language: ru
x-frame-options: DENY
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Server: nginx
Date: Wed, 30 Oct 2013 12:15:48 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=30
X-Powered-By: PHP/5.3.27
X-Content-Type-Options: nosniff
Location: https://api.worldoft...application_id=<�мой_апп_ID>&redirect_uri=http://test.com/callback.php
Content-Language: ru
x-frame-options: DENY
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
armor_kiev: Ключевые места выделены жирным и подчеркиванием.
Суть проблемы:
1) Токен серверного приложения открыто (через http-запросы) проходит через браузер клиента;
2) В данный момент API авторизации не работоспособно т.к. заголовок с редиректом отправляется с моего сервера в браузер клиента и уже из браузера запрашивается страница авторизации с сервера API. IP браузера клиента, естественно, не совпадает с моим зарегистрированным IP и клиент не может авторизоваться из-за ошибки проверки IP.
3) Разнобой терминологии. В пользовательском соглашении речь идет про Токен, в кабинете разработчика и ссылках используется application_id.
Замечание:
Судя из пп. 5.3.-5.4 пользовательского соглашения "Токен" является закрытой информацией. В частности: "Пользователь самостоятельно и в полном объёме несёт ответственность за использование и сохранность Токена" и "Все действия, совершенные с использованием Токена Пользователя, считаются совершенными Пользователем лично".
Получается очень некрасиво. Сам механизм работы API фактически раскрывает Токен любому желающему, но, тем не менее, за сохранность отвечаю я и за любые действия от имени этого открытого не по моей вине ключа отвечаю тоже я.
Решение проблемы (вариант):
1) запрос auth/login проходит через клиента, поэтому не должен содержать токен, вполне достаточно redirect_uri, из которого и так очевидно кто запрашивает (так же см. п. 3);
2) запрос auth/login не должен быть привязан к IP сервера в любом случае (даже во время теста), т.к. фактически приводит к неработоспособности данной возможности;
3) должно быть два ключа:
token - секретный ключ, которым сервер пользователя идентифицирует себя перед сервером API в закрытых запросах, которые осуществляются напрямую между серверами (например: auth/prolongate);
application_id - открытый ключ приложения для операций, где клиент перенаправляется на сервер API (например: auth/login). Такие запросы априори не могут считаться как высланные сервером пользователя, их результаты должны требовать проверки дополнительным закрытым прямым запросом с использованием token. Действия с application_id может совершить кто угодно, но только действия с token должны считаться совершенными лично пользователем.
Вообще правильным вариантом считаю убрать нафиг API авторизации и выложить толковые инструкции и примеры кода по использованию OpenID, который и так опробовал и вполне нормально работает. Получается, что два дня потратил зря на API вместо того, чтобы привязать к новому сервису уже готовый механизм.
Суть проблемы:
1) Токен серверного приложения открыто (через http-запросы) проходит через браузер клиента;
2) В данный момент API авторизации не работоспособно т.к. заголовок с редиректом отправляется с моего сервера в браузер клиента и уже из браузера запрашивается страница авторизации с сервера API. IP браузера клиента, естественно, не совпадает с моим зарегистрированным IP и клиент не может авторизоваться из-за ошибки проверки IP.
3) Разнобой терминологии. В пользовательском соглашении речь идет про Токен, в кабинете разработчика и ссылках используется application_id.
Замечание:
Судя из пп. 5.3.-5.4 пользовательского соглашения "Токен" является закрытой информацией. В частности: "Пользователь самостоятельно и в полном объёме несёт ответственность за использование и сохранность Токена" и "Все действия, совершенные с использованием Токена Пользователя, считаются совершенными Пользователем лично".
Получается очень некрасиво. Сам механизм работы API фактически раскрывает Токен любому желающему, но, тем не менее, за сохранность отвечаю я и за любые действия от имени этого открытого не по моей вине ключа отвечаю тоже я.
Решение проблемы (вариант):
1) запрос auth/login проходит через клиента, поэтому не должен содержать токен, вполне достаточно redirect_uri, из которого и так очевидно кто запрашивает (так же см. п. 3);
2) запрос auth/login не должен быть привязан к IP сервера в любом случае (даже во время теста), т.к. фактически приводит к неработоспособности данной возможности;
3) должно быть два ключа:
token - секретный ключ, которым сервер пользователя идентифицирует себя перед сервером API в закрытых запросах, которые осуществляются напрямую между серверами (например: auth/prolongate);
application_id - открытый ключ приложения для операций, где клиент перенаправляется на сервер API (например: auth/login). Такие запросы априори не могут считаться как высланные сервером пользователя, их результаты должны требовать проверки дополнительным закрытым прямым запросом с использованием token. Действия с application_id может совершить кто угодно, но только действия с token должны считаться совершенными лично пользователем.
Вообще правильным вариантом считаю убрать нафиг API авторизации и выложить толковые инструкции и примеры кода по использованию OpenID, который и так опробовал и вполне нормально работает. Получается, что два дня потратил зря на API вместо того, чтобы привязать к новому сервису уже готовый механизм.
Проблемы и заявки об ошибках Wargaming Public API