skobkin

Если нужно быть на 100% уверенными, что пришедший пользователь - тот, за кого себя выдаёт - API будет получше, чем OpenID. Можно с полученным токеном ткнуться в API обратно и запросить какое-нибудь приватное поле, например. Если же оно нужно для самого игрока, а не для внутренних расчётов системы - тогда всё равно. OpenID будет помнеьше даже пугать тем, что не просит доступ к золоту и т.п.

Бегреп: Нажимаем на вход. На сайте Варгейминга отказываемся от предоставления данных. Попадаем на пустую страницу.Третьему разработчику за вечер этот багреп отправляю :) Удачи на конкурсе!

Легко вычисляется из полей statistics.all.battles и statistics.all.wins в методе account/info.

Много чего, много где и, вероятнее всего, натянуть на динамику. У меня к вам встречный "правильный" вопрос: что мне нужно сделать, чтобы накат увеличился? P.S. Эта тема предназначена для вопросов по WGDPP и WG Public API. На такие пространные вопросы вам никто здесь не ответит. И учить делать сайты тоже никто не будет.

Тут и тут уже расписали.

В общем, судя по всему, суть моего вопроса и его причину никто не понял :) А до первого ответа он исчерпал себя сам, т.к. я разобрался в механизме аутентификации через API. Можно считать закрытым. Тут описал всё, что нужно было. Ссылка содержит account_id. Дополнительный текст - это, скорее всего, название провайдера OpenID. Думаю, убрать его будет несложно. account_id есть и в ссылке на профиль. Правда, если нужен именно он - правильнее будет его получать из того места, которое для этого предназначено - из API, а то начнётся сплошной быдлокод. Меня в API немного печалит, что, в отличие от OpenID напрямую, приложение не добавляется в доверенные и при запросе аутентификации пользователя будут постоянно просить дать подтверждение. С одной стороны это понятно - всё же даётся доступ к приватным данным. С другой стороны - на других сервисах, где используется тот же OAuth такой доступ дается раз и навсегда (до ручного удаления приложения из доверенных). При аутентификации же через OpenID пользователя никто не будет спрашивать ни о чём, если он уже разрешил сайту получить его данные и при наличии куки на сервисах WG, он будет возвращён обратно на сайт с данными.

Ну так если access_token не получать, то можно и обычным OpenID пользоваться - и модулей писать не придётся.

То есть, у вас нет цели сохранить никнейм из первого запроса, а нужен вам только account_id? Тогда да, конечно, во втором запросе вам вернётся валидный. Но если кто-то захочет поддерживать соответствие юзернейма танковому при регистрации - нужно будет либо сравнивать account_id первого и второго запросов, либо вместо prolongate делать запрос к информации об аккаунте. В моём случае регистрация пользователей на стороне сервера производится без каких-либо телодвижений с его стороны, а значит ник должен 100% соответствовать игровому.

Ну, вы продляете токен - тоже вариант. Можно выполнить любой метод API, который может использовать только сам пользователь, либо которые вернут его account_id. Вопрос был не в этом. Вопрос был в том, как аутентифицировать пользователя с серверным application_id. Я в документации запутался. Отдельно вопрос по вашему сорцу. А где вы проверяете, что токен именно этого пользователя? Вот я иду с помощью вашего приложения получаю аутентификацию на твинка, но редирект обратно к вам подправляю и в строке запроса меняю юзернейм и идентификатор аккаунта на данные аккаунта SerB, например. Вам приходит мой токен и данные СерБа. Вы выполняете продление токена, но не сверяете accound_id, поэтому у вас в БД я буду записан как SerB. Поправьте меня, если я ошибаюсь.

А. Ну если так - то да, нет ни одной CMS, которая поддерживает аутентификацию через WG API. Есть только поделки тех, кто пилил свои проекты. API это появилось не так давно. Да и суть его не столько в аутентификации, сколько в получении токена, который в CMS просто так не нужен. Кстати, если уж на то пошло, то разработчики API всё же сделали не очень хорошую документацию. То, что метод называется "ВХОД ПО OPENID", но является совсем не OpenID, а специфическим методом API - это очень неинтуитивно. Я тоже сначала думал, что мне будет достаточно использовать FpOpenIdBundle для взаимодействия с ним, но позже заметил, что в OpenID и здесь отправляются разные наборы данных. Божественно. Не покажете пример кода, который ломает запятая? Очень интересно. UPD: Ответ ЦПП по поводу использования одного токена на двух application_id и аутентификации с серверного приложения: То есть, насколько я понимаю схему аутентификации через API, у серверной части моего приложения не может быть 100% уверенности в валидности токена для аккаунта, который вернулся вместе с редиректнутым пользователем. Так как злоумышленник может вернуться в систему, например, с токеном от твинка, при этом вернув чужие ник и идентификатор. При этом, насколько я понимаю, проверять на 100% не получится, если не запрашивать с сервера с помощью клиентского application_id профайл и проверять наличие данных в секции "private". А при использовании клиентского application_id сразу сильно режется количество запросов в секунду. UPD: Понял наконец-то как для серверной части работает аутентификация. Вопросы снимаются. Всё хорошо. Если кому-то интересно, то вкратце: 1. Сервер запрашивает метод аутентификации с серверным application_id, nofollow=1 и redirect_uri с указанным адресом, на который будут приняты данные обратно на сервер. 2. API возвращает в ответе на какой адрес нужно направить пользователя. 3. Сервер отправляет пользователя туда. Уже с таким специальным URL'ом API не ругается на невалидный IP. 4. Пользователь возвращается с теми же данными, что и на автономном приложении на страницу redirect_uri сервера. То есть, для сервера добавляется ещё один шаг в цепочке - получение уникального адреса для редиректа пользователя. Ну и, так как токен получен на серверный ID, то уже можно значительно чаще запрашивать информацию о профилях пользователей.

Возьмите уже плагин OpenID для Wordpress или любой другой CMS (1, 2, 3, 4, 5, ...). Вы здесь с какими-то банальностями вопросы задаёте. Если не получается разобраться даже с установкой плагина, то какая речь о разработке проекта? Слишком громкое заявление не подкреплённое ничем. Можно обратиться в Google с запросом типа "CMS OpenID support", например.

Доброго времени суток товарищам девелоперам. Пишу клиент-серверное приложение, которое будет работать с API сервеной частью, но для получения токена аутентификация происходит в дополнительном окошке клиента: 1. Открывается страница проверки статуса аутентификации пользователя на сервере 2. Если пользователь не идентифицирован, то происходит редирект на API входа через OpenID. 3. После входа и/или одобрения доступа клиент возвращается на определенную страницу на сервере (redirect_uri). 4. Сервер узнает account_id пользователя и получает access_token для дальнейшей работы с данными игрока (получение инфы о клане и данных профиля). Но в этой схеме возникла проблема: Так как все запросы данных происходят с сервера, я зарегистрировал приложение как серверное. И при попытке запроса метода аутентификации я, разумеется, получаю отлуп с ошибкой "INVALID_IP_ADDRESS". Конечно, при переключении приложения в режим автономного всё работает. Но тогда у меня, само собой, урезается количество запросов в секунду, что может быть очень критично. Отсюда вылезает два вопроса: 1. Можно ли как-то проходить аутентификацию пользователя с application_id серверного приложения? 2. Можно ли завести два application_id для клиента и сервера, и использовать токен полученный клиентом на сервере? Благодарю за помощь. UPD: Ответ ЦПП.

Не порите чушь.

Вот, делал тесты на эту тему. Вторая часть - про маскировку.

Та же самая ***, только сообщение в консоли чуть другое. Установите Windows и не парьтесь.