Реклама | Adv
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
  • Rotator
Сообщения форума
Реклама | Adv

Обсуждение практических вопросов использования Wargaming Public API

Дата: 02.10.2014 16:51:00
Просмотр сообщенияThe_IzeBerg (02 Окт 2014 - 15:25) писал: Может и для продления сделать "галочку", тыкнув которую пользователь дает приложению право на постоянное продление токена, а без нее продление только через пользователя (пользователь сам продлевает)?

MustBeDead:  

Просмотр сообщенияtujh_ural (02 Окт 2014 - 16:23) писал: Спасибо, теперь понятнее стало. А нельзя просто подобным токенам, сгенерированным в ЛК, назначить флаг "не продлевать" при выдаче на сервере? То есть, даже если "злой" разработчик захочет продлить токен - ему прилетит "отбивка" от сервера.   Если задаю глупые вопросы - то извините, я не знаком с OpenID и подобными технологиями, занимаюсь программированием исключительно десктопных приложений и узкоспециализированных.

MustBeDead:   Ситуация состоит в особенностях реализации двух методов аутентификации. Если говорить упрощенно, доверенный хост OpenID привязан к пользователю (по сути, к его странице http://worldoftanks.ru/community/accounts/20840149-tujh_ural/), при аутентификации методами Public API access_token - application_id - является ключом данного значения, но также валидируется еще account_id.   Разработчику нет необходимости использовать OpenID. Предоставление приватных данных не производится. Передается минимальное количество информации - ссылка на профиль портала, откуда можно "выдрать" игровое имя и идентификатор. Для десктоп приложения мне неизвестно для каких целей может быть необходима данная информация.   Из улучшений аутентификации методами Public API, вижу только отсутствие необходимости пользователю указывать свою регистрационную информацию. Например, создав ключ с необходимыми правами доступа в новом разделе Личного кабинета портала. Вопрос состоит в другом, техническое обоснование данной необходимости.Так как придется изменить схему аутентификации полностью. Я не поддерживаю разделение информации на части - критическая информация не передается (данные авторизации - логин, пароль; платежи, номер телефона), передается только несущественная информация, перечень которой перечисляется в подтверждении операции. Если есть необходимость скрыть, например, количество фишек клана, то можно отказать от аутентификации. Остаток игрового золота, кредитов и информация о бане, считаю, персональной, но не секретной.   Сайт разработчиков OpenID. Спецификация. Документация аутентификация методами Public API - методы auth/login, auth/prolongate, auth/logout. Не могу не напомнить, что это методы аутентификации, а не авторизации у Вас на портале, приложении или продукте.

Реклама | Adv