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


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


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

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

    Шутюзела

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

pro2s #282 Отправлено 04 ноя 2013 - 15:08

    Сержант

  • Игроки
  • 24267 боев
  • 105
  • [PRO2S] PRO2S
  • Регистрация:
    17.02.2012
Статистика игроков в режиме "Командный бой" планируется отдаться через API ?

MustBeDead #283 Отправлено 04 ноя 2013 - 18:32

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

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

Просмотр сообщенияpro2s (04 Ноя 2013 - 15:08) писал:

Статистика игроков в режиме "Командный бой" планируется отдаться через API ?

Спасибо за Ваше пожелание.
Режим "Командный бой" введен в игровой процесс после обновления 8.9 (29 октября 2013 года).
Возможность выборки данных по командной статистике (метод account/info) будет рассмотрена в ближайшее время. Дополнительную информацию по данному факту мы обязательно сообщим в данной теме.
Кабинет разработчика Wargaming Developer Partner Program

thunderspb #284 Отправлено 05 ноя 2013 - 14:06

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

  • Бета-тестеры
  • 10190 боев
  • 814
  • [BD] BD
  • Регистрация:
    04.06.2010
Вообщем есть предолжение. которе, я думаю устроит многих.
1. Было бы полезно иметь данные по бану игрока, т.е. я предлагаю вынести поля private.restrictions.*, private.ban_time и private.ban_info из приватных данных. Я не вижу причины не иметь к ним доступ без access_token. В частности это помогло бы проектам, которые формируют и подбирают взводы. Да и для проектов типа WoT ClanStat (статистика для клансайтов) помогла бы командирам и ответственным видеть баны своих подчиненных.
2. Access_token это здОрово, однако не дает проектам необходимой инфы по пользователю, поскольку чтобы ее получить пользователя надо залогинить и это не позволяет собирать инфу в авфтоматическом режиме. Поэтому предложение. Сделать возможность для пользователя создать статический access_token для своего профиля. А далее пользоватьель совершенно самостоятельно "выдает" этот токен кому он хочет со всеми втекающими и вытекающими. Я согласен, что ВСЮ инфу наверное все же не стоит выдавать, однако такие данные как
- Танки в ангаре
- Серебро/Золото (?)
- Премимум акк, дата окончания (?)
- Опыт свободный (?)
- Online/Offline
- возможно-чтото-еще

(?) -- означает, что я бы выдачу таких данных сделал бы на основе чекбокса, т.е. на user access_token я могу выставить галочками те данные, которые я хочу чтобы были доступны по этому access_token
Лимитировать количество access_token для пользователя, например, 5ью штуками.
Посути такой же механизм я бы сделал и для клановой отдачи

Как раз сейчас вход через апи позволяет сайту получить теже данные, да, единоразово, но я, например, не хочу чтобы этот сайт получал эти данные, но, допустим, я не могу зайти на сайт не залогинившись через WG AuthAPI. Помоему это косяк и причем нехилый, если отталкиваться от многих постов про "я не хочу давать свои данные" и про то как КВГ борется с приватностью данных пользователей.
Более того, почему отдается это поле: "is_bound_to_phone": true, Нафига сайту или кому либо еще это знать?? Хорошо хоть емыла там нет :)

Если можно, то ответить по пунктам, желательно с комментариями.
Все, что вы хотели узнать про статистику онлайна с преферансом и куртизанками графиками покластерно и посерверно: https://stats.wotapi.ru/

CrazySys #285 Отправлено 05 ноя 2013 - 19:31

    Старшина

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

Просмотр сообщенияthunderspb (05 Ноя 2013 - 14:06) писал:

(?) -- означает, что я бы выдачу таких данных сделал бы на основе чекбокса, т.е. на user access_token я могу выставить галочками те данные, которые я хочу чтобы были доступны по этому access_token
Лимитировать количество access_token для пользователя, например, 5ью штуками.
Посути такой же механизм я бы сделал и для клановой отдачи
На мой взгляд это уже перебор.

ЕМНИП, количество пользователей с повышенным ЧСВ которое они пытаются выпячивать на показ - ничтожно мало по сравнению с общим кол-вом пользователей, которым в принципе почти все пофиг и их устраивает текущее состояние дел, и ни о какой танко-1c, а уж тем более private-блоках они даже не задумываются.
То есть данный функционал, на мой взгляд, будет мало востребован, "галочек" никто специально ходить и ставить не будет, а по умолчанию их выставлять - отгрести очередную порцию массового вайна =).
Да и наверняка реализация подобного функционала достаточно сложна, в масштабах десятков миллионов пользователей. К тому же с этими "галочками" не долго скатиться до ситуации "этому - вот этот танк показать, другому вон тот, а этот не показывать" .

ИМХО гораздо проще реализовать в личном кабинете список приложений получивших токен доступа к private-инфе, с возможностью управлять его содержанием (по аналогии с доверенными сайтами).

Мне кажется логичнее оставить аутентификацию на откуп нативным библиотекам openID. То есть разделить аутентификацию пользователя (openID), и авторизацию приложений на получение private-данных (pAPI), сделав так, что второе невозможно без первого, но не наоборот.

Добившись этим того, что если приложение хочет получить доступ к private-информации - оно обязано спросить дополнительное разрешение у пользователя и уведомить его о возможности автоматизированного сбора этой информации в дальнейшем. При этом, такое подтверждение со стороны пользователя должно быть не галкой, не просто кнопкой, а кнопкой ведущей на страницу повторного ввода пароля (если конечно этого приложения еще нет в списке доверенных). В этом плане страница "Подтверждение операции" сделана верно.

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

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

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

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


 


y88 #286 Отправлено 06 ноя 2013 - 08:16

    Рядовой

  • Игроки
  • 28991 бой
  • 5
  • [KB-2C] KB-2C
  • Регистрация:
    15.10.2010
Для api.worldoftanks.ru/wot/account/tanks/ - техника игрока
statistics - Статистика техники
statistics.battles - Проведено боёв - не попадают командные бои - это так и задумано?

Пожалуйста, оставьте данные по танкам.
statistics.all.capture_points
statistics.all.damage_dealt
statistics.all.damage_received
statistics.all.dropped_capture_points
statistics.all.frags
statistics.all.hits
statistics.all.losses
statistics.all.shots
statistics.all.spotted
statistics.all.survived_battles
statistics.all.wins
statistics.all.xp

morecal #287 Отправлено 06 ноя 2013 - 14:31

    Сержант

  • Игроки
  • 26108 боев
  • 162
  • [LUTRO] LUTRO
  • Регистрация:
    17.10.2010
Можно ли внедрить реализацию http заголовка Last-Modified или ETag. А также соотвественно поддежрку If-Modified-Since и If-none-match

Техническая реализация вроде бы не сложная. Профиты.

1. Меньше нагрузка на ваши сервера.
2. Меньший траффик клиента апи в случае, если запрошенные данные совпадают с уже отданными. ( Например задача синхронизации базы данных кланов/танков )

Hedeon #288 Отправлено 06 ноя 2013 - 16:37

    Старшина

  • Разработчики
  • 20729 боев
  • 567
  • [WG-A] WG-A
  • Регистрация:
    30.12.2010

Просмотр сообщенияthunderspb (05 Ноя 2013 - 14:06) писал:

Вообщем есть предолжение. которе, я думаю устроит многих.
1. Было бы полезно иметь данные по бану игрока, т.е. я предлагаю вынести поля private.restrictions.*, private.ban_time и private.ban_info из приватных данных. Я не вижу причины не иметь к ним доступ без access_token. В частности это помогло бы проектам, которые формируют и подбирают взводы. Да и для проектов типа WoT ClanStat (статистика для клансайтов) помогла бы командирам и ответственным видеть баны своих подчиненных.
2. Access_token это здОрово, однако не дает проектам необходимой инфы по пользователю, поскольку чтобы ее получить пользователя надо залогинить и это не позволяет собирать инфу в авфтоматическом режиме. Поэтому предложение. Сделать возможность для пользователя создать статический access_token для своего профиля. А далее пользоватьель совершенно самостоятельно "выдает" этот токен кому он хочет со всеми втекающими и вытекающими. Я согласен, что ВСЮ инфу наверное все же не стоит выдавать, однако такие данные как
- Танки в ангаре
- Серебро/Золото (?)
- Премимум акк, дата окончания (?)
- Опыт свободный (?)
- Online/Offline
- возможно-чтото-еще

(?) -- означает, что я бы выдачу таких данных сделал бы на основе чекбокса, т.е. на user access_token я могу выставить галочками те данные, которые я хочу чтобы были доступны по этому access_token
Лимитировать количество access_token для пользователя, например, 5ью штуками.
Посути такой же механизм я бы сделал и для клановой отдачи

Как раз сейчас вход через апи позволяет сайту получить теже данные, да, единоразово, но я, например, не хочу чтобы этот сайт получал эти данные, но, допустим, я не могу зайти на сайт не залогинившись через WG AuthAPI. Помоему это косяк и причем нехилый, если отталкиваться от многих постов про "я не хочу давать свои данные" и про то как КВГ борется с приватностью данных пользователей.
Более того, почему отдается это поле: "is_bound_to_phone": true, Нафига сайту или кому либо еще это знать?? Хорошо хоть емыла там нет :)

Если можно, то ответить по пунктам, желательно с комментариями.
1. Пока наша позиция такова, что информация по блокировке учетной записи это строго приватная информация пользователя. Но этот вопрос будет вынесен на обсуждение в ближайшее время. Каких либо сроков внесения изменений, в случае принятия такого решения, назвать не могу.
2. Давать возможность пользователю делигировать свой access token пока не планируется. Однако, есть идеи о создании отдельных публичных ключей с контролем доступа и о выдаче пользователю возможности мониторить приложения, которым был выдан access token, и возможности произвести вылогинивание в момент, когда пользователю это будет надо. Сроков опять же не называю.

Просмотр сообщенияy88 (06 Ноя 2013 - 08:16) писал:

Для api.worldoftanks.ru/wot/account/tanks/ - техника игрока
statistics - Статистика техники
statistics.battles - Проведено боёв - не попадают командные бои - это так и задумано?

Пожалуйста, оставьте данные по танкам.
statistics.all.capture_points
statistics.all.damage_dealt
statistics.all.damage_received
statistics.all.dropped_capture_points
statistics.all.frags
statistics.all.hits
statistics.all.losses
statistics.all.shots
statistics.all.spotted
statistics.all.survived_battles
statistics.all.wins
statistics.all.xp
Информацию по режиму "Командный бой" получить с помощью API пока невозможно. Мы работаем над появлением данного функционала. Поля "statistics" сейчас передаются только для поддержания формата ответа и не несут информации. Возможно, данные из поля "statistics" будут добавлены в будущем отдельным методом.

Просмотр сообщенияmorecal (06 Ноя 2013 - 14:31) писал:

Можно ли внедрить реализацию http заголовка Last-Modified или ETag. А также соотвественно поддежрку If-Modified-Since и If-none-match

Техническая реализация вроде бы не сложная. Профиты.

1. Меньше нагрузка на ваши сервера.
2. Меньший траффик клиента апи в случае, если запрошенные данные совпадают с уже отданными. ( Например задача синхронизации базы данных кланов/танков )
Спасибо за предложение, оно будет рассмотрено нами.

thunderspb #289 Отправлено 06 ноя 2013 - 17:09

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

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

Просмотр сообщенияHedeon (06 Ноя 2013 - 16:37) писал:

1. Пока наша позиция такова, что информация по блокировке учетной записи это строго приватная информация пользователя. Но этот вопрос будет вынесен на обсуждение в ближайшее время. Каких либо сроков внесения изменений, в случае принятия такого решения, назвать не могу.
А что на счет поля is_bound_to_phone ? По мне так это более приватная инфа, чем бан... Както не видится мне, что эта инфа прям такая уж приватная.

Просмотр сообщенияHedeon (06 Ноя 2013 - 16:37) писал:

2. Давать возможность пользователю делигировать свой access token пока не планируется. Однако, есть идеи о создании отдельных публичных ключей с контролем доступа и о выдаче пользователю возможности мониторить приложения, которым был выдан access token, и возможности произвести вылогинивание в момент, когда пользователю это будет надо. Сроков опять же не называю.
Ну я про публичные ключи и говорил, может не совсем точно выразился... Это было бы удобнее. Как правильно заметил CrazySys -- авторизация должна быть отдана OpenID, никаких других поидее не должно быть. Получение приватных данных -- паблик кейз...
Все, что вы хотели узнать про статистику онлайна с преферансом и куртизанками графиками покластерно и посерверно: https://stats.wotapi.ru/

Hedeon #290 Отправлено 06 ноя 2013 - 17:36

    Старшина

  • Разработчики
  • 20729 боев
  • 567
  • [WG-A] WG-A
  • Регистрация:
    30.12.2010

Просмотр сообщенияthunderspb (06 Ноя 2013 - 17:09) писал:

А что на счет поля is_bound_to_phone ? По мне так это более приватная инфа, чем бан... Както не видится мне, что эта инфа прям такая уж приватная.
Ну я про публичные ключи и говорил, может не совсем точно выразился... Это было бы удобнее. Как правильно заметил CrazySys -- авторизация должна быть отдана OpenID, никаких других поидее не должно быть. Получение приватных данных -- паблик кейз...
Поле is_bound_to_phone выдается только при введении access token и не является публичным. Оно может быть полезно, например, для напоминания человеку о том, что у него не привязан телефон к учетной записи и желательно осуществить привязку. Оно ведь не содержит какой либо информации о номере, на который осуществлена привязка, только сам факт ее наличия.
Касательно авторизации - сейчас этот метод плотно анализируется на предмет улучшений. Нам очень помогают фидбеки, которые постятся в этой теме для поиска возможных путей для улучшения.

thunderspb #291 Отправлено 06 ноя 2013 - 17:49

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

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

Просмотр сообщенияHedeon (06 Ноя 2013 - 17:36) писал:

Поле is_bound_to_phone выдается только при введении access token и не является публичным. Оно может быть полезно, например, для напоминания человеку о том, что у него не привязан телефон к учетной записи и желательно осуществить привязку. Оно ведь не содержит какой либо информации о номере, на который осуществлена привязка, только сам факт ее наличия.
Ну я вот совершенно уверен, что кроме сайта ВГ больше никто не будет делать напоминалку, что акк не привязан к телефону :)
Ну свое мнение по авторизации и доступам я и CrazySys озвучили, было бы конечно неплохо, чтобы и остальные участники высказались...
Спасибо за инфу.
Все, что вы хотели узнать про статистику онлайна с преферансом и куртизанками графиками покластерно и посерверно: https://stats.wotapi.ru/

RadarMTS #292 Отправлено 06 ноя 2013 - 19:40

    Ефрейтор

  • Игроки
  • 21304 боя
  • 37
  • [CADRR] CADRR
  • Регистрация:
    13.10.2011
Ну с привязкой к телефону я пожалуй соглашусь - она кроме как ВГ уж точно никому не нужна особо.
А вот что касается инфы по банам - нужна! Вот представьте - я весь такой сознательный КЛ далеко не топового клана, но и не клана "круглосуточноиграющихдетей" и по сути человек военный, поэтому когда клан всей толпой выходит в ротные бои, на тренировки и в командные покатушки мне важна дисциплина. У меня, да и думаю во многих кланах в уставе есть такой пункт - "не нарушать правил игры", но по сути я не могу узнать нарушает ли кто-то из моих игроков правила игры. Был случай - мне один соклан написал, что был в бане пару дней, но за ерунду какую-то. И я не могу проверить - может он у меня идиот и в рандоме хаит весь белый свет самыми матерными словами, которые он успел выучить, а в клане прикидывается адекватным человеком. А Вы же представляете что из-за одного неадеквата могут про весь клан понапридумывать)))

Это как пример, той ситуации в которой было бы не плохо выдавать хоть какую-то часть информации по прошлым наказаниям игрока и его нынешнем статусе (бан, не бан).

MustBeDead #293 Отправлено 07 ноя 2013 - 12:37

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

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

Просмотр сообщенияRadarMTS (06 Ноя 2013 - 19:40) писал:

Ну с привязкой к телефону я пожалуй соглашусь - она кроме как ВГ уж точно никому не нужна особо.А вот что касается инфы по банам - нужна! Вот представьте - я весь такой сознательный КЛ далеко не топового клана, но и не клана "круглосуточноиграющихдетей" и по сути человек военный, поэтому когда клан всей толпой выходит в ротные бои, на тренировки и в командные покатушки мне важна дисциплина. У меня, да и думаю во многих кланах в уставе есть такой пункт - "не нарушать правил игры", но по сути я не могу узнать нарушает ли кто-то из моих игроков правила игры. Был случай - мне один соклан написал, что был в бане пару дней, но за ерунду какую-то. И я не могу проверить - может он у меня идиот и в рандоме хаит весь белый свет самыми матерными словами, которые он успел выучить, а в клане прикидывается адекватным человеком. А Вы же представляете что из-за одного неадеквата могут про весь клан понапридумывать)))Это как пример, той ситуации в которой было бы не плохо выдавать хоть какую-то часть информации по прошлым наказаниям игрока и его нынешнем статусе (бан, не бан).

Благодарим за дополнительную информацию.
Данный вопрос будет обсуждаться в ближайшее время. Возможно, будут внесены изменения.
На данный момент информация по блокировке учетной записи - строго приватная информация пользователя.
Кабинет разработчика Wargaming Developer Partner Program

xiilliix #294 Отправлено 07 ноя 2013 - 14:00

    Новобранец

  • Игроки
  • 41 бой
  • 2
  • Регистрация:
    15.11.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.

Сколько уже можно мусолить вопрос авторизации? Переживаете что данные авторизации попадут клиенту и их украдут трояны? Ну дык не передавайте клиенту ничего, пускай сервер сам сделает все запросы, пройдёт по всем редиректам, узнает ответ и если ответ "ок", то логиньте чувака к себе на сайт :)

Управление авторизацией в руках вашего сервера. Короче всё нормально с безопасностью OpenID и Wargaming.net ID.
Короче, вот этот запрос "http:// мой-сайт.ру/login?&status=ok&access_token=2dba994dec1901b296a01709fcdf332d9d925813&nickname=armor_kiev&account_id=94868&expires_at=1384171147" не должен попадать к клиенту, а только сервера далжны общаться между собой такими буквами :)
Вам же надо только узнать, авторизован пользователь или нет, а это вам прийдёт в колбек.

armor_kiev #295 Отправлено 07 ноя 2013 - 14:03

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

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

Просмотр сообщенияMustBeDead (07 Ноя 2013 - 12:37) писал:

На данный момент информация по блокировке учетной записи - строго приватная информация пользователя.
Это не тот атрибут, который должен быть приватным.
К слову. Когда вопросами безопасности занимаются узкопрофильные специалисты ("чисто админ"), то получаются такие требования: "пароль менять каждые 2 месяца. 8 символов, обязательно должна быть цифра, прописная буква и непохожесть на старый пароль". Чисто с технической точки зрения требования хорошие. А социальная инженерия на нулевом уровне. Так вот, в очередной раз меняю в пароле к рабочей почте 3 на 4, а не дает - схожесть, переставляю местами - схожесть. Плюнул, вспомнил как в одном хозяйственном суде, где был сильный "админ-железячник", наблюдал стикеры с паролями на каждом втором мониторе, и первый раз в жизни принципиально написал пароль на стикер и прилепил к монитору.

Просмотр сообщенияxiilliix (07 Ноя 2013 - 14:00) писал:

Управление авторизацией в руках вашего сервера. Короче всё нормально с безопасностью OpenID и Wargaming.net ID.
Товарищ не читатель? Таки да, с OpenID и Wargaming.net ID все в порядке - претензий не имеется.

Сообщение отредактировал armor_kiev: 07 ноя 2013 - 14:06


thunderspb #296 Отправлено 07 ноя 2013 - 14:05

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

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

Просмотр сообщенияxiilliix (07 Ноя 2013 - 14:00) писал:

Сколько уже можно мусолить вопрос авторизации? Переживаете что данные авторизации попадут клиенту и их украдут трояны? Ну дык не передавайте клиенту ничего, пускай сервер сам сделает все запросы, пройдёт по всем редиректам, узнает ответ и если ответ "ок", то логиньте чувака к себе на сайт :)
Управление авторизацией в руках вашего сервера. Короче всё нормально с безопасностью OpenID и Wargaming.net ID.
Короче, вот этот запрос "http:// мой-сайт.ру/login?&status=ok&access_token=2dba994dec1901b296a01709fcdf332d9d925813&nickname=armor_kiev&account_id=94868&expires_at=1384171147" не должен попадать к клиенту, а только сервера далжны общаться между собой такими буквами :)
Вам же надо только узнать, авторизован пользователь или нет, а это вам прийдёт в колбек.
Эт в каком месте мой сервер может управлять авторизацией? пользователю нужно ввести логин/пароль либо получить подтверждение что он залогинен, это все рельзовано редиректами с, обратка прозходит через комп пользователя показывая и application_id и access_token...
Вы чтото путаете... Хоть firebug включите и посмотрите что куда и с какими данными уходит-приходит
зыж имелось ввиду конечно же авторизация через API, с OpenID все пучком :) Я и предлагаю оставить только OpenID :) Все остальные личные данные через персональные паблик ключи

Сообщение отредактировал thunderspb: 07 ноя 2013 - 14:09

Все, что вы хотели узнать про статистику онлайна с преферансом и куртизанками графиками покластерно и посерверно: https://stats.wotapi.ru/

Drahtigel #297 Отправлено 07 ноя 2013 - 14:12

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

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

Просмотр сообщенияxiilliix (07 Ноя 2013 - 14:00) писал:

Управление авторизацией в руках вашего сервера. Короче всё нормально с безопасностью OpenID и Wargaming.net ID.
Короче, вот этот запрос "http:// мой-сайт.ру/login?&status=ok&access_token=2dba994dec1901b296a01709fcdf332d9d925813&nickname=armor_kiev&account_id=94868&expires_at=1384171147" не должен попадать к клиенту, а только сервера далжны общаться между собой такими буквами :)
Вам же надо только узнать, авторизован пользователь или нет, а это вам прийдёт в колбек.
Товарищ видимо совсем не читатель, ибо речь не только о взаимодействии сервер-сервер, и совсем не в openID.

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

 


xiilliix #298 Отправлено 07 ноя 2013 - 14:16

    Новобранец

  • Игроки
  • 41 бой
  • 2
  • Регистрация:
    15.11.2012

Просмотр сообщенияthunderspb (07 Ноя 2013 - 14:05) писал:

Эт в каком месте мой сервер может управлять авторизацией? пользователю нужно ввести логин/пароль либо получить подтверждение что он залогинен, это все рельзовано редиректами с, обратка прозходит через комп пользователя показывая и application_id и access_token...
Вы чтото путаете... Хоть firebug включите и посмотрите что куда и с какими данными уходит-приходит
зыж имелось ввиду конечно же авторизация через API, с OpenID все пучком :) Я и предлагаю оставить только OpenID :) Все остальные личные данные через персональные паблик ключи
не, не путаю. в новой версии авторизации, которая в закрытом тесте, всё именно так. Он безопасен.

thunderspb #299 Отправлено 07 ноя 2013 - 14:24

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

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

Просмотр сообщенияxiilliix (07 Ноя 2013 - 14:16) писал:

не, не путаю. в новой версии авторизации, которая в закрытом тесте, всё именно так. Он безопасен.
В авторизации через паблик АПИ необходимо, чтобы application_id был Автономным, это сделано потому, что для авторизации пользоователя его надо РЕДИРЕКТИТЬ на сайт WG и получать оттуда подтверждение, надеюсь не надо объяснять почему... в строке редиректа БУДЕТ присутсвовать application_id светящийся на стороне клиента/пользователя и обратно сайт редиректит тебя в return_url с access_token...  НЕ засветить ни то ни другое не получится. Более того, полученный access_token НЕ будет работать в связке с Серверным application_id ибо он не был авторизован через этот application_id.
Может конечно у Вас другая информация и Вы участвует в более закрытом тесте... :) В моем тесте это работает именно так.
Все, что вы хотели узнать про статистику онлайна с преферансом и куртизанками графиками покластерно и посерверно: https://stats.wotapi.ru/

Drahtigel #300 Отправлено 07 ноя 2013 - 14:52

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

  • Игроки
  • 44543 боя
  • 333
  • [IS-23] IS-23
  • Регистрация:
    31.07.2011
Вопрос по структуре player.achievements, а не проще ли её отдавать именованным списком, по сути ведь это массив типа numeric, да и обрабатывать было бы удобнее как Dicrionary(Of String, Integer), а не приведённую структуру? Пусть даже с разбивкой по типам ачивок, но списками?

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

 


MustBeDead #301 Отправлено 07 ноя 2013 - 15:02

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

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

Просмотр сообщенияarmor_kiev (07 Ноя 2013 - 14:03) писал:

Это не тот атрибут, который должен быть приватным.
К слову. Когда вопросами безопасности занимаются узкопрофильные специалисты ("чисто админ"), то получаются такие требования: "пароль менять каждые 2 месяца. 8 символов, обязательно должна быть цифра, прописная буква и непохожесть на старый пароль". Чисто с технической точки зрения требования хорошие. А социальная инженерия на нулевом уровне. Так вот, в очередной раз меняю в пароле к рабочей почте 3 на 4, а не дает - схожесть, переставляю местами - схожесть. Плюнул, вспомнил как в одном хозяйственном суде, где был сильный "админ-железячник", наблюдал стикеры с паролями на каждом втором мониторе, и первый раз в жизни принципиально написал пароль на стикер и прилепил к монитору.

Политика приватности данных будет пересмотрена.

Просмотр сообщенияthunderspb (07 Ноя 2013 - 14:24) писал:

В авторизации через паблик АПИ необходимо, чтобы application_id был Автономным, это сделано потому, что для авторизации пользоователя его надо РЕДИРЕКТИТЬ на сайт WG и получать оттуда подтверждение, надеюсь не надо объяснять почему... в строке редиректа БУДЕТ присутсвовать application_id светящийся на стороне клиента/пользователя и обратно сайт редиректит тебя в return_url с access_token...  НЕ засветить ни то ни другое не получится. Более того, полученный access_token НЕ будет работать в связке с Серверным application_id ибо он не был авторизован через этот application_id.
Может конечно у Вас другая информация и Вы участвует в более закрытом тесте... :) В моем тесте это работает именно так.

До исправления ошибки авторизации с серверным типом приложения, использовать access_token можно только с того application_id, для которого он был получен. До внесения изменений, к сожалению, это только автономные типы приложений.
Кабинет разработчика Wargaming Developer Partner Program




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

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