Перейти к содержимому


Отзывы и пожелания. Wargaming Public API


  • Закрытая тема Тема закрыта
Сообщений в теме: 369

BYBY3EJIA #261 Отправлено 15 авг 2013 - 12:59

    Шутюзела

  • Игроки
  • 38661 бой
  • 14 725
  • Регистрация:
    30.10.2010
В этой теме публикуем свои предложения и пожелания.

MustBeDead #262 Отправлено 23 окт 2013 - 10:13

    Старший сержант

  • Игроки
  • 2868 боев
  • 286
  • Регистрация:
    22.04.2012

Просмотр сообщенияshizzard (22 Окт 2013 - 19:21) писал:

Спасибо, это очень хорошо :)
Есть небольшое предложение, которое я не ожидаю увидеть реализованным в ближайшее время, но которое очень хочется увидеть рано или поздно в методах API. Речь идет о возможности получения истории онлайна игрока. Эти данные были бы очень полезны для вычисления времени прайм-тайма игрока с целью подыскать ему наиболее удобный взвод. Конечно, отдавать историю всех сессий игрока - это слишком, но можно ограничиться хотя бы тем, что отдавать онлайн игрока за последний месяц, исключая сессии продолжительностью меньше, скажем, 15 минут. Я к тому, что технически это реализовать можно в виде sliding window, например, это несложно и с точки зрения кодинга и с точки зрения хранения информации.
Остается лишь вопрос о том, насколько правомерным будет такой метод, это уже, все-таки, не игровая статистика, а нечто, имеющее отношение непосредственно к самому игроку.

Спасибо за предложение.
Ранее было внесено аналогичное предложение. В данный момент оно находится на рассмотрении.
Кабинет разработчика Wargaming Developer Partner Program

Yury_SNEGOV #263 Отправлено 24 окт 2013 - 07:37

    Младший лейтенант

  • Игроки
  • 45627 боев
  • 1 101
  • Регистрация:
    13.12.2011

Просмотр сообщенияMustBeDead (22 Окт 2013 - 19:07) писал:

Все так и происходит.
Танкист состоит в клане: https://api.worldoft...ount_id=4354591

{
"status": "ok",
"count": 1,
"data": {
"4354591": {
"clan": {
"role_i18n": "Заместитель командира",
"clan_id": 8105,
"role": "vice_leader",
"since": 1349534040
},

Не состоит: https://api.worldoft...ount_id=6416452

{
"status": "ok",
"count": 1,
"data": {
"6416452": {
"clan": null,
"achievements": {

Так ведь

СПРАВОЧНИК API сказал:

clan  Информация об участнике клана
Внимание! Поле будет отключено.
Используйте метод clan/membersinfo.
...Потому и просим оставить.

Юзербар от сервиса WOT-O-Matic

wotomatic.net - подробная статистика игроков и кланов, рейтинги, генератор юзербаров


MustBeDead #264 Отправлено 24 окт 2013 - 10:02

    Старший сержант

  • Игроки
  • 2868 боев
  • 286
  • Регистрация:
    22.04.2012

Просмотр сообщенияYury_SNEGOV (24 Окт 2013 - 07:37) писал:


Так ведь

...Потому и просим оставить.

Просмотр сообщенияYury_SNEGOV (17 Окт 2013 - 06:16) писал:

Поддержу предыдущий пост. К примеру, присутствие в account/info элементарного "clan_id": null уже избавит от ненужного запроса clan/membersinfo. Равно как наличие "clan_id": NNNN будет расценено как необходимость сразу запросить clan/info, без опять же лишнего в данном случае запроса clan/membersinfo.

Благодарю за предложение. Мы обязательно его рассмотрим.
Кабинет разработчика Wargaming Developer Partner Program

shizzard #265 Отправлено 27 окт 2013 - 02:30

    Сержант

  • Игроки
  • 24937 боев
  • 122
  • [IMBSQ] IMBSQ
  • Регистрация:
    27.06.2010
Господа разработчики, у меня созрело несколько пожеланий и отзывов.
Я снова доехал до gap'а в базе игроков - до идентификаторов, которых нет в базе (около 9-го миллиона и дальше). В связи с этим появились странные вещи в мониторинге http-запросов:
Spoiler                     
Как видно, из-за уменьшения времени ответа практически до нуля резко увеличилось количество запросов. При этом резко увеличилось как число 200-х ответов, так и число 503-х. Меня это как-то насторожило, и я полез копать. Вот что я увидел в теле ответа 503:
Spoiler                     
Господа, если вы отдаете 503 на отлуп по рейтам, то это необходимо указывать в документации. Иначе некоторые идиоты вроде меня так и будут долбить по вам с оверлоадом, не понимая "а какого хрена валятся 5хх". Может, на другие ошибки будут отдаваться другие коды HTTP?
Второй вопрос уже конкретно по рейтам. Если вы не против, задам его здесь, раз уж здесь начал разливать вайн.
Лимит запросов, который был мной установлен на гейте, равен 10 (на графике видно, что лимит не превышен). Это число было указано товарищем MustBeDead. Не сомневаюсь, что оно верное и это действительный лимит. Но вот проблема в том, что секунда - понятие растяжимое. Поясню.
Простейший пример. У меня есть лимит в один запрос в секунду. Я произвожу запросы:
0.00 - 0.21 R1
1.00 - 1.25 R2
2.00 - 2.19 R3
Сработает ли в этом случае флуд-контроль? Между окончанием запроса R1 и началом запроса R2 прошло меньше секунды - 0.79. Конкретный вопрос: интервал между запросами считается на момент начала запроса или на момент окончания?
Второй пример. Лимит 5 запросов в секунду. Тайминги:
0.00 - 0.05 R1
0.00 - 0.11 R2
0.00 - 0.02 R3
0.00 - 0.19 R4
0.00 - 0.08 R5
Все пять запросов лежат в пределах одной секунды. Такой порядок запросов будет определен флуд-контролем как, собственно, флуд? Или, все же, нужно лупить запросы с интервалом (1/Limit), как в примере ниже? Сейчас я работаю именно по такой схеме: в начале каждой секунды я вытаскиваю из очереди до десяти запросов и запускаю выполнение. Это верный подход или же нет? Или правильно, все же, вот так:
0.00 - 0.05 R1
0.20 - 0.31 R2
0.40 - 0.42 R3
0.60 - 0.79 R4
0.80 - 0.88 R5

Я прошу подробнее просветить общественность по поводу механизмов работы лимитов. Спасибо.

Сообщение отредактировал shizzard: 27 окт 2013 - 02:43

Свободное общение на тему разработки под WG Public API: xmpp://wg-papi@conference.jabber.ru

MustBeDead #266 Отправлено 28 окт 2013 - 11:54

    Старший сержант

  • Игроки
  • 2868 боев
  • 286
  • Регистрация:
    22.04.2012

Просмотр сообщенияshizzard (27 Окт 2013 - 02:30) писал:

Господа разработчики, у меня созрело несколько пожеланий и отзывов.
Я снова доехал до gap'а в базе игроков - до идентификаторов, которых нет в базе (около 9-го миллиона и дальше). В связи с этим появились странные вещи в мониторинге http-запросов:
Spoiler                     
Как видно, из-за уменьшения времени ответа практически до нуля резко увеличилось количество запросов. При этом резко увеличилось как число 200-х ответов, так и число 503-х. Меня это как-то насторожило, и я полез копать. Вот что я увидел в теле ответа 503:
Spoiler                     
Господа, если вы отдаете 503 на отлуп по рейтам, то это необходимо указывать в документации. Иначе некоторые идиоты вроде меня так и будут долбить по вам с оверлоадом, не понимая "а какого хрена валятся 5хх". Может, на другие ошибки будут отдаваться другие коды HTTP?

Согласен. Рассмотрим возможность добавления данной ошибки в документацию.
Ошибка 503 подразумевает под собой превышение количества запросов к ресурсу.

Просмотр сообщенияshizzard (27 Окт 2013 - 02:30) писал:

Второй вопрос уже конкретно по рейтам. Если вы не против, задам его здесь, раз уж здесь начал разливать вайн.
Лимит запросов, который был мной установлен на гейте, равен 10 (на графике видно, что лимит не превышен). Это число было указано товарищем MustBeDead. Не сомневаюсь, что оно верное и это действительный лимит. Но вот проблема в том, что секунда - понятие растяжимое. Поясню.
Простейший пример. У меня есть лимит в один запрос в секунду. Я произвожу запросы:
0.00 - 0.21 R1
1.00 - 1.25 R2
2.00 - 2.19 R3
Сработает ли в этом случае флуд-контроль? Между окончанием запроса R1 и началом запроса R2 прошло меньше секунды - 0.79. Конкретный вопрос: интервал между запросами считается на момент начала запроса или на момент окончания?
Второй пример. Лимит 5 запросов в секунду. Тайминги:
0.00 - 0.05 R1
0.00 - 0.11 R2
0.00 - 0.02 R3
0.00 - 0.19 R4
0.00 - 0.08 R5
Все пять запросов лежат в пределах одной секунды. Такой порядок запросов будет определен флуд-контролем как, собственно, флуд? Или, все же, нужно лупить запросы с интервалом (1/Limit), как в примере ниже? Сейчас я работаю именно по такой схеме: в начале каждой секунды я вытаскиваю из очереди до десяти запросов и запускаю выполнение. Это верный подход или же нет? Или правильно, все же, вот так:
0.00 - 0.05 R1
0.20 - 0.31 R2
0.40 - 0.42 R3
0.60 - 0.79 R4
0.80 - 0.88 R5

Я прошу подробнее просветить общественность по поводу механизмов работы лимитов. Спасибо.

Учитывайте, пожалуйста, время берется в расчет именно при приеме запроса на севере, а не на клиентской машине (сервере).
При условии, что тайминг запросов приведен именно с Nginx, запросы будут успешно обработаны без нарушения квотирования.
Кабинет разработчика Wargaming Developer Partner Program

shizzard #267 Отправлено 28 окт 2013 - 13:54

    Сержант

  • Игроки
  • 24937 боев
  • 122
  • [IMBSQ] IMBSQ
  • Регистрация:
    27.06.2010

Просмотр сообщенияMustBeDead (28 Окт 2013 - 11:54) писал:

Учитывайте, пожалуйста, время берется в расчет именно при приеме запроса на севере, а не на клиентской машине (сервере).
При условии, что тайминг запросов приведен именно с Nginx, запросы будут успешно обработаны без нарушения квотирования.

Не знаю, как вам по имени, буду звать Мастом Бидедовичем :)
Маст Бидедович, у вас поразительная способность отвечать на вопрос не ответив на него :) У меня аж дыханье сперло. Будут успешно обработаны без нарушения квотирования в каком случае? Во всех?

Окей, может, получится разобраться вместе?
Вот что я сделал. Я изменил логику вываливания запросов из очереди. Теперь в начале каждой секунды из очереди вытаскивается до десяти (RPS) запросов, которые затем планируются на выполнение с delay в n*(1000/RPS) для энного запроса. Чтобы стало понятнее, просто приведу кусочек дебаг-лога, он должен все прояснить:

Spoiler                     

Знаете, помогло! Где-то с пару минут после рестарта гейта не было ни одной ошибки. Я уж было подумал, что вот оно, счастье разработчика, ан нет. Ошибки снова посыпались. Это странно, особенно с учетом того, что в секунду запускалось не более двух запросов, так как остальные висели в ожидании ответа.
Я подумал о том, что можно бы увеличить количество воркеров до 20. Сразу же отмечу: количество воркеров - это не RPS, это количество процессов, которые кладут задачи в очередь. Количество воркеров влияет только на количество конкурентных запросов к API, то есть в одно время может выполняться не более 20 запросов с разрешенным рейтом в 10 RPS. Из-за времени выполнения запросов к /account/tanks сейчас как раз 20 конкурентных запросов и висит:

(hydra@10.128.14.71)71> supervisor:count_children(hydra_pulsar_worker_sup).
[{specs,1},{active,20},{supervisors,0},{workers,20}]


Так вот теперь график выглядит ну уж очень характерно:

Spoiler                     

Видите, какой график рваный? У меня пока есть только два возможных объяснения такого поведения.
Первое: лимит на количество конкурентных запросов. Маловероятно, потому что ошибки валятся как на 10, так и на 20.
Второе: особенности работы механизма квотирования. Если представить себе, что бэкенд API немного перегружен и входящие запросы nginx ставит в очередь, а квотирование обсчитывается уже на апстримах, то я вполне могу себе представить, что некоторое количество запросов попадает в апстрим в один момент, вызывая отлупы. Если я прав, то исправить это можно либо попробовав обсчитывать квотирование на nginx (не уверен, что это можно сделать не дописывая модулей), либо пробрасывать реальное время поступления запроса в апстрим в каком-нибудь кастомном хедере вроде X-А-Вот-Тут-Лежит-Истинное-Время-Поступления-Запроса-На-Фронт.

В общем, товарищи, я прошу у вас помощи, потому как я уже сделал все, что мог. У меня все еще валятся REQUEST_LIMIT_EXCEEDED, хотя я запускаю не больше 10 запросов в секунду. Готов предоставить любые графики, логи - что угодно. Например, вот характерный кусок лога с ошибками:

Spoiler                     

Спасибо!
Свободное общение на тему разработки под WG Public API: xmpp://wg-papi@conference.jabber.ru

armor_kiev #268 Отправлено 28 окт 2013 - 15:49

    Младший лейтенант

  • Игроки
  • 15809 боев
  • 1 379
  • [CLOH] CLOH
  • Регистрация:
    15.07.2010
Попробовал авторизацию через API (пока пользуюсь классическими методами OpenID без API).
По-моему есть очевидные дыры в безопасности.
Предположим, что я делаю авторизацию через API в лоб (а для теста функционала так и сделал).
Что возвращает сервер авторизации? Примерно такой URL:
http:// мой-сайт.ру/login?&status=ok&access_token=2dba994dec1901b296a01709fcdf332d9d925813&nickname=armor_kiev&account_id=94868&expires_at=1384171147
Итак, предположим, что я все сделал тупо в лоб. Что мешает злоумышленнику попытаться войти на мой сайт этой же самой ссылкой с другими nickname и account_id?
Ничего не помешает, ведь статус "ок" :) Проверять реферер? Можно подделать.
access_token? Что это и зачем? Оно тупо идет в открытом виде и я на своей стороне не знаю какой именно должен придти access_token, подделан он или подставлен перехваченный злоумышленником.
Т.е. для поддержания безопасности на минимальном уровне необходимо делать неочевидные и незадокументированные вещи:
1) сохранять в сессии информацию о факте отправки запроса на авторизацию;
2) создавать свой уникальный секретный ключ, который на текущий момент использовать пока только параметром в redirect_uri (например: &skey=dfgsfw4y76yh6uyeth) - по получению ответа сравнивать со значением в сессии и сбрасывать, повторный прием уже недопустим.
3) Может что еще - подскажите кому не жалко.
Безопасность в данном случае важнейший элемент, поэтому
Предлагаю
1) к описанию протокола добавить четкие пошаговые инструкции и примеры кода, которые показывали бы методы решения (обхода) описанных выше проблем;
2) в параметры запроса на вход добавить обязательный параметр: уникальный секретный ключ, который генерируется на стороне запрашивающего сервера и отправляться может исключительно get или post запросом с сервера, а не посредством ссылки или формы в браузере клиента. Ключ возвращать в ответе сервера авторизации. С этим разобрались - решается проверкой токена через auth/prolongate.

Сообщение отредактировал armor_kiev: 28 окт 2013 - 17:55


shizzard #269 Отправлено 28 окт 2013 - 16:03

    Сержант

  • Игроки
  • 24937 боев
  • 122
  • [IMBSQ] IMBSQ
  • Регистрация:
    27.06.2010

Просмотр сообщенияarmor_kiev (28 Окт 2013 - 15:49) писал:

Попробовал авторизацию через API (пока пользуюсь классическими методами OpenID без API).
По-моему есть очевидные дыры в безопасности.
Предположим, что я делаю авторизацию через API в лоб (а для теста функционала так и сделал).
Что возвращает сервер авторизации? Примерно такой URL:
http:// мой-сайт.ру/login?&status=ok&access_token=2dba994dec1901b296a01709fcdf332d9d925813&nickname=armor_kiev&account_id=94868&expires_at=1384171147
Итак, предположим, что я все сделал тупо в лоб. Что мешает злоумышленнику попытаться войти на мой сайт этой же самой ссылкой с другими nickname и account_id?
Ничего не помешает, ведь статус "ок" :) Проверять реферер? Можно подделать.
access_token? Что это и зачем? Оно тупо идет в открытом виде и я на своей стороне не знаю какой именно должен придти access_token, подделан он или подставлен перехваченный злоумышленником.
Т.е. для поддержания безопасности на минимальном уровне необходимо делать неочевидные и незадокументированные вещи:
1) сохранять в сессии информацию о факте отправки запроса на авторизацию;
2) создавать свой уникальный секретный ключ, который на текущий момент использовать пока только параметром в redirect_uri (например: &skey=dfgsfw4y76yh6uyeth) - по получению ответа сравнивать со значением в сессии и сбрасывать, повторный прием уже недопустим.
3) Может что еще - подскажите кому не жалко.
Безопасность в данном случае важнейший элемент, поэтому
Предлагаю
1) к описанию протокола добавить четкие пошаговые инструкции и примеры кода, которые показывали бы методы решения (обхода) описанных выше проблем;
2) в параметры запроса на вход добавить обязательный параметр: уникальный секретный ключ, который генерируется на стороне запрашивающего сервера и отправляться может исключительно get или post запросом с сервера, а не посредством ссылки или формы в браузере клиента.

Смысл access_token в том, что ваше приложение может стукнуться к Варгеймингу и спросить, есть ли такой access_token и кто за ним прячется.
http://openid.net/sp...8.html#userinfo
Свободное общение на тему разработки под WG Public API: xmpp://wg-papi@conference.jabber.ru

armor_kiev #270 Отправлено 28 окт 2013 - 16:18

    Младший лейтенант

  • Игроки
  • 15809 боев
  • 1 379
  • [CLOH] CLOH
  • Регистрация:
    15.07.2010

Просмотр сообщенияshizzard (28 Окт 2013 - 16:03) писал:

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

Хорошо, иными словами: чтобы обеспечить достаточную безопасность необходимо:
а) авторизовать пользователя через auth/login
б) используя access_token проверить ID пользователя и срок авторизации через auth/prolongate

только после этого считать, что пользователь "чист".

Т.е., собственно, это и есть необходимость той самой инструкции по безопасности при авторизации.
Мне, например, операция продления Access Token по решаемым задачам вообще нафиг не нужна, поэтому ее использовать и не собирался. Но для подтверждения факта авторизации, да, воспользуюсь.


shizzard #271 Отправлено 28 окт 2013 - 16:21

    Сержант

  • Игроки
  • 24937 боев
  • 122
  • [IMBSQ] IMBSQ
  • Регистрация:
    27.06.2010

Просмотр сообщенияarmor_kiev (28 Окт 2013 - 16:18) писал:

Хорошо, иными словами: чтобы обеспечить достаточную безопасность необходимо:
а) авторизовать пользователя через auth/login
б) используя access_token проверить ID пользователя и срок авторизации через auth/prolongate

только после этого считать, что пользователь "чист".

Т.е., собственно, это и есть необходимость той самой инструкции по безопасности при авторизации.
Мне, например, операция продления Access Token по решаемым задачам вообще нафиг не нужна, поэтому ее использовать и не собирался. Но для подтверждения факта авторизации, да, воспользуюсь.

Ну протокол OpenID открытый, и там sequence описан достаточно подробно. Может быть, достаточно ссылки на спеки.
Свободное общение на тему разработки под WG Public API: xmpp://wg-papi@conference.jabber.ru

armor_kiev #272 Отправлено 28 окт 2013 - 16:28

    Младший лейтенант

  • Игроки
  • 15809 боев
  • 1 379
  • [CLOH] CLOH
  • Регистрация:
    15.07.2010

Просмотр сообщенияshizzard (28 Окт 2013 - 16:21) писал:

Ну протокол OpenID открытый, и там sequence описан достаточно подробно. Может быть, достаточно ссылки на спеки.

А я сразу и написал, что WG OpenID использую уже давно, сейчас решил попробовать API. Авторизация через API это, в смысле протокола взаимодействия, не OpenID, а надстройка над ним, поэтому документация к OpenID тут на мой взгляд мало применима.


MustBeDead #273 Отправлено 29 окт 2013 - 11:58

    Старший сержант

  • Игроки
  • 2868 боев
  • 286
  • Регистрация:
    22.04.2012

Просмотр сообщенияarmor_kiev (28 Окт 2013 - 15:49) писал:

Попробовал авторизацию через API (пока пользуюсь классическими методами OpenID без API).
По-моему есть очевидные дыры в безопасности.
Предположим, что я делаю авторизацию через API в лоб (а для теста функционала так и сделал).
Что возвращает сервер авторизации? Примерно такой URL:
http:// мой-сайт.ру/login?&status=ok&access_token=2dba994dec1901b296a01709fcdf332d9d925813&nickname=armor_kiev&account_id=94868&expires_at=1384171147
Итак, предположим, что я все сделал тупо в лоб. Что мешает злоумышленнику попытаться войти на мой сайт этой же самой ссылкой с другими nickname и account_id?
Ничего не помешает, ведь статус "ок" :) Проверять реферер? Можно подделать.
access_token? Что это и зачем? Оно тупо идет в открытом виде и я на своей стороне не знаю какой именно должен придти access_token, подделан он или подставлен перехваченный злоумышленником.
Т.е. для поддержания безопасности на минимальном уровне необходимо делать неочевидные и незадокументированные вещи:
1) сохранять в сессии информацию о факте отправки запроса на авторизацию;
2) создавать свой уникальный секретный ключ, который на текущий момент использовать пока только параметром в redirect_uri (например: &skey=dfgsfw4y76yh6uyeth) - по получению ответа сравнивать со значением в сессии и сбрасывать, повторный прием уже недопустим.
3) Может что еще - подскажите кому не жалко.
Безопасность в данном случае важнейший элемент, поэтому
Предлагаю
1) к описанию протокола добавить четкие пошаговые инструкции и примеры кода, которые показывали бы методы решения (обхода) описанных выше проблем;
2) в параметры запроса на вход добавить обязательный параметр: уникальный секретный ключ, который генерируется на стороне запрашивающего сервера и отправляться может исключительно get или post запросом с сервера, а не посредством ссылки или формы в браузере клиента. Ключ возвращать в ответе сервера авторизации. С этим разобрались - решается проверкой токена через auth/prolongate.

Спасибо за предложение. Мы обязательно его рассмотрим.
Возможно, в метод auth/login будут введены дополнительные возможности.
Кабинет разработчика Wargaming Developer Partner Program

Softovick #274 Отправлено 30 окт 2013 - 16:19

    Ефрейтор

  • Игроки
  • 12842 боя
  • 36
  • [AQV] AQV
  • Регистрация:
    17.02.2012
Не нашел в теме, рискну написать. Интересует, ведется ли статистика использования Application ID и есть ли возможность или планы по просмотру этих данных?
Я думаю, что как минимум разработчику было бы интересно смотреть, как часто были обращения к Application ID, какого вида запросы и с каких IP, какие данные туда передавались и отдавались (хотя бы обычный текст json).
С одной стороны, это можно делать и на стороне клиента, в коде которые подключается. Но это не будет давать общего статуса использования, особенно в случае автономного приложения.
Что думаете по этому поводу?

armor_kiev #275 Отправлено 30 окт 2013 - 19:38

    Младший лейтенант

  • Игроки
  • 15809 боев
  • 1 379
  • [CLOH] CLOH
  • Регистрация:
    15.07.2010

Просмотр сообщенияSamurayDjek (30 Окт 2013 - 16:19) писал:

С одной стороны, это можно делать и на стороне клиента, в коде которые подключается.

В соответствии с пользовательским соглашением это нельзя делать на стороне клиента.


Softovick #276 Отправлено 30 окт 2013 - 19:43

    Ефрейтор

  • Игроки
  • 12842 боя
  • 36
  • [AQV] AQV
  • Регистрация:
    17.02.2012

Просмотр сообщенияarmor_kiev (30 Окт 2013 - 19:38) писал:

В соответствии с пользовательским соглашением это нельзя делать на стороне клиента.
Нельзя хранить лог запросов и данные, полученные от WG?

armor_kiev #277 Отправлено 30 окт 2013 - 19:51

    Младший лейтенант

  • Игроки
  • 15809 боев
  • 1 379
  • [CLOH] CLOH
  • Регистрация:
    15.07.2010

Просмотр сообщенияSamurayDjek (30 Окт 2013 - 19:43) писал:

Нельзя хранить лог запросов и данные, полученные от WG?
Нельзя использовать application_id (он же "токен") на стороне клиента. Это закрытая информация, которую должен знать только Пользователь и сервер API.

Сообщение отредактировал armor_kiev: 30 окт 2013 - 19:54


thunderspb #278 Отправлено 30 окт 2013 - 23:40

    Младший лейтенант

  • Бета-тестеры
  • 10190 боев
  • 814
  • [BD] BD
  • Регистрация:
    04.06.2010

Просмотр сообщенияarmor_kiev (30 Окт 2013 - 19:51) писал:

Нельзя использовать application_id (он же "токен") на стороне клиента. Это закрытая информация, которую должен знать только Пользователь и сервер API.
НЕсколько  не точно :) Автономный ИД позволяет использать ИД на стороне клиента, ондако не очень понятно как можно сделать так, чтобы клиент этот ИД не вытащил, собственно поэтому описание API 2.0 и явилось раньше заявления о официальном тесте. КРейзи и циклоп уже писали и спрашивали про то, что для авторизации пользователя необходимо сделать редирект пользователя на сайт КВГ с указанием Автономного ИД, чтобы получить подтверждение, но этот АПП_ИД будет выден пользвателю... На основе этого и был запрос к разрабам на предмет best practices... "а воз и ныне там"...
На мой личный взгляд, данная реализация несколько неправильна, для доступа к личным данным необходимо сделать чтото на подобие ключей доступа к личным данным пользователя, как это реализовано в EVE Online... Если кому интересно, то могу расписать подробнее свое видение этого.
Грубо гогворя -- авторизация это авторизация, только подтверждение, что пользователь  существует в игре. Далее, пользователь САМ в СВОЕМ кабинете делает "ключ" для доступа к своим данным ( например это можно реализовать галочками -- даю доступ до моих золотых, танков в ангаре и т.п.). Ессно это все в read-only! Ну и далее дает этот ключ кому он сам хочет. Это было бы идеальным решением проблемы и идеальной защищенностью тех данных, которые пользователь не хочет отдавать. Однако все данные, которые КВГ считает обще доступными, например те, которые выводятся на сайте, должны отдаваться запросу без наличия "управляющего" ключа.
На мой взгляд это было бы самым лучшим решением и для разработчиков и для сторонних разработчиков и для пользователей.
Все, что вы хотели узнать про статистику онлайна с преферансом и куртизанками графиками покластерно и посерверно: https://stats.wotapi.ru/

STREJlA #279 Отправлено 31 окт 2013 - 03:47

    Старшина

  • Игроки
  • 14734 боя
  • 410
  • [W_G_P] W_G_P
  • Регистрация:
    25.10.2010

Просмотр сообщенияthunderspb (30 Окт 2013 - 23:40) писал:

НЕсколько  не точно :) Автономный ИД позволяет использать ИД на стороне клиента, ондако не очень понятно как можно сделать так, чтобы клиент этот ИД не вытащил, собственно поэтому описание API 2.0 и явилось раньше заявления о официальном тесте. КРейзи и циклоп уже писали и спрашивали про то, что для авторизации пользователя необходимо сделать редирект пользователя на сайт КВГ с указанием Автономного ИД, чтобы получить подтверждение, но этот АПП_ИД будет выден пользвателю... На основе этого и был запрос к разрабам на предмет best practices... "а воз и ныне там"...
На мой личный взгляд, данная реализация несколько неправильна, для доступа к личным данным необходимо сделать чтото на подобие ключей доступа к личным данным пользователя, как это реализовано в EVE Online... Если кому интересно, то могу расписать подробнее свое видение этого.
Грубо гогворя -- авторизация это авторизация, только подтверждение, что пользователь  существует в игре. Далее, пользователь САМ в СВОЕМ кабинете делает "ключ" для доступа к своим данным ( например это можно реализовать галочками -- даю доступ до моих золотых, танков в ангаре и т.п.). Ессно это все в read-only! Ну и далее дает этот ключ кому он сам хочет. Это было бы идеальным решением проблемы и идеальной защищенностью тех данных, которые пользователь не хочет отдавать. Однако все данные, которые КВГ считает обще доступными, например те, которые выводятся на сайте, должны отдаваться запросу без наличия "управляющего" ключа.
На мой взгляд это было бы самым лучшим решением и для разработчиков и для сторонних разработчиков и для пользователей.
Прощай авторизация в один клик.

Drahtigel #280 Отправлено 31 окт 2013 - 08:51

    Старший сержант

  • Игроки
  • 44543 боя
  • 333
  • [IS-23] IS-23
  • Регистрация:
    31.07.2011

Просмотр сообщенияthunderspb (30 Окт 2013 - 23:40) писал:

НЕсколько  не точно :) Автономный ИД позволяет использать ИД на стороне клиента, ондако не очень понятно как можно сделать так, чтобы клиент этот ИД не вытащил, собственно поэтому описание API 2.0 и явилось раньше заявления о официальном тесте. КРейзи и циклоп уже писали и спрашивали про то, что для авторизации пользователя необходимо сделать редирект пользователя на сайт КВГ с указанием Автономного ИД, чтобы получить подтверждение, но этот АПП_ИД будет выден пользвателю... На основе этого и был запрос к разрабам на предмет best practices... "а воз и ныне там"...
На мой личный взгляд, данная реализация несколько неправильна, для доступа к личным данным необходимо сделать чтото на подобие ключей доступа к личным данным пользователя, как это реализовано в EVE Online... Если кому интересно, то могу расписать подробнее свое видение этого.
Грубо гогворя -- авторизация это авторизация, только подтверждение, что пользователь  существует в игре. Далее, пользователь САМ в СВОЕМ кабинете делает "ключ" для доступа к своим данным ( например это можно реализовать галочками -- даю доступ до моих золотых, танков в ангаре и т.п.). Ессно это все в read-only! Ну и далее дает этот ключ кому он сам хочет. Это было бы идеальным решением проблемы и идеальной защищенностью тех данных, которые пользователь не хочет отдавать. Однако все данные, которые КВГ считает обще доступными, например те, которые выводятся на сайте, должны отдаваться запросу без наличия "управляющего" ключа.
На мой взгляд это было бы самым лучшим решением и для разработчиков и для сторонних разработчиков и для пользователей.
У яндекса с APP_ID та же система, что и у WG почти, единственное, что у Яндекса подтверждение (на стороне пользователя), что пользователь разрешает приложению использовать. А вот каким образом защитить AppID я сам чешу репу. Шифруй-не шифруй, найдётся гад с дебаггером и массой свободного времени... :trollface:

Сайт клана IS-23

 


CrazySys #281 Отправлено 02 ноя 2013 - 00:01

    Старшина

  • Игроки
  • 14205 боев
  • 637
  • Регистрация:
    17.01.2011

Просмотр сообщенияSTREJlA (31 Окт 2013 - 03:47) писал:

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

Просмотр сообщенияDrahtigel (31 Окт 2013 - 08:51) писал:

Шифруй-не шифруй, найдётся гад с дебаггером и массой свободного времени... :trollface:
Мы тут очередь занимаем, да =)

Сообщение отредактировал CrazySys: 02 ноя 2013 - 00:04

WoTLogger - узнай о своих боях всё! =)

Доступна новая версия WoTLogger – реализация идеи, ставшей одной из победителей в проводившемся компанией «Wargaming» конкурсе разработчиков «WGDC» и занявшей первое место в номинации «Лучшая идея».

Подробности на http://alfa.wotlogger.ru и нашем форуме (forum.wotlogger.ru)


 





Количество пользователей, просматривающих этот форум: 1

0 пользователей, 0 гостей, 0 анонимных