Отправили меня на третью страницу темы - я пошел все читать.

Tiendil

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

P.S. Сейчас API методов для получения информации о городах и прочем нет. Если что-то конкретное надо — пиши, постраюсь скорректировать планы по реализации.

Я лучше сделаю получение информации о городе отдельным вызовом, так правильнее будет.

Есть реальная необходимость.

Два Цвета

введите авторизацию для приложения, не многие хотят вводить свой логин пароль

Tiendil

Пока авторизовываться вообще нечему. Когда появится что-то работающее, тогда и подумаем над этим.

Аналогично, это необходимо.

Два Цвета

в http://the-tale.org/guide/api#game_info нет описания is_boss для action.

Tiendil

Его нет сознательно, т.к. пока мне кажется, что ему место не в том месте :-)

Тоже хорошо бы задокументировать.

Tiendil

Grin

Эм… я не совсем понял как с помощью API выбрать способность героя(Удар, Удар Вампира, Бродяга и тд)…

Пока не реализовано, будет сделано, когда появится хоть какой-нибудь законченый клиент.

Granulkur

Вопрос: будут ли добавлены предпочтения героя в info? Т.е. любимая добыча, союзник, противник, город и т.п.
Упростит сбор статистики

В info добавлено не будет. Возможно, появится аналогичный запрос для получения всей инфы о герое, но в ближайшее время работ по api не предполагается.

У меня пока страницы с информацией о герое нет, но будет; это тоже нужно.

Это пожелания от разработчика одного из альтернативных клиентов, чтобы разработчик основного приложения о них не забыл, а не поторапливания)
Ок, надеюсь, это будет.

Авторизация с помощью разрешений на сайте.
Допустим, пользователь хочет дать доступ к аккаунту приложению на телефоне. Отправляется запрос, приходит в ответ ссылка с каким-то гуидом для конкретного запроса. Правильно ли я понимаю, что если пользователь хочет с компьютера дать разрешение приложению на телефоне, ему придется перепечатывать эту ссылку на компьютер?

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

Может быть, стоит дать возможность указывать логин, которому придет запрос на авторизацию приложения? Тогда можно отправить запрос с телефона, на компьютере открыть раздел "Приложения", дать разрешение и продолжить работу на телефоне.

Tiendil

Тогда появится возможность спамить запросами — послал запросы всем пользователям и жди кто ответит. Поэтому запрос никак не привязан к конкретному пользователю. Кто перешёл по ссылке, подтвердил, тот и пользователь.

Да, такая проблема, конечно, есть, и решается она только усложнением... Например, можно в application_info передавать случайно сгенерированный токен, который отобразится и на устройстве при запросе, и в браузере на компьютере, и сверять его.
Ну хорошо, спасибо.

Кстати, было бы удобно в ответ на запрос информации об игре добавить параметр с последним проявлением религиозности.

Tiendil

Информация об игре и так сильно разрослась. Если и добавлять, то в какой-нибудь вспомогательный метод для получения полной информации о герое, когда он появится.

Согласен, в любом случае, хорошо было бы добавить.

У меня вопрос по Авторизации:
полученный token (отправленный пользователю) нужно впихнуть в sessionid?

Ок, опишу подробней:
1. Посылаем пользователя по сгенерированной ссылке (к примеру, http://the-tale.org/accounts/third-party/tokens/8e5db0e3-22a3-4a1c-bac5-c21e4f7aecbf)
2. На своей странице пользователь подтверждает.
3. Сохраняю в куки значение sessionid=8e5db0e322a34a1cbac5c21e4f7aecbf; csrftoken="оставляю прежним".
4. Посылаю POST-запрос, прикрекпляю к нему куки, а ответ простой: "Залогиньтесь"

Что я делаю не так?

Токен для third-party authorization никак не связан с сессионной кукой.

Спасибо, разобрался :)