Такая возможность есть
Есть методы которые расчитаны только на пользовательскую сессию - работают от имени пользователя.
Есть методы которые расчитаны работать вне сессии пользователя.
Эти подмножества пересекаются, то есть ряд методов работают как по сессии, так и без неё (подпись ключем приложения), но метод вроде users.getCurrentUser логично что к таким не относитя. А вот, например, users.getInfo относится
Возможно, есть ряд методов которых действительно по валидным причинам должна быть возможность вызывать вне сессии - мы можем добавить такой режим.
Ну в настройках приложения можно получить вечный токен для вашего пользователя, которым вы можете пользоваться для вызова сессионных методов. Только сессия будет ваша и пользователь там будете вы)
Вообще в ОК все сессии - пользовательские, поэтому без пользователя получить серверную сессию все равно не выйдет. Так что надо либо передавать сессию на сервер и там валидировать (все равно же передаете), либо проходить не клиентский а серверный OAUTH, когда токен получаете через REST запрос, и тогда передаете клиенту сессию для использования.
Валидность сессии подтверждается успешным вызовом, из ответа получаем id пользователя сессии.
Получение экспирации сессии вещь ненадежная - с одной стороны есть пермиссии которые позволяют делать автопродлеваемые сессии, которые могут жить годами, с другой - пользователь может в любой момент запретить приложению далее работать под его именем.
app_secret_key в запросе участвовать не будет - куда вы планируете его передавать? есть запросы сессионные (клиентские, подписываются сессионным ключем) и несессионные (в том числе серверные, подписанные ключем приложения). В данном случае вы передаете сессию, поэтому подписываете запрос секретным ключем сессии'
KattyB: А какая цель преследуется в подобном запросе?
Личная лента, которую вы запрашиваете - да, это события, совершенные им. Общая лента - это личная лента + подмешенные ленты друзей, групп, рекомендаций и так далее
Владимир Сорокин: Возможно не выдается, Валерий лучше ситуацию знает по конкретной пермиссии. Мой ответ - это общий подход к ситуации, когда требуется какая-то пермиссия приложению - у кого и как спрашивать.
vermus: ну во-первых часть сервисов дают не реальный емейл пользователя, а виртуальный, которые через них форвардится. в ОК было решено - с одной стороны - пользователь должен напрямую указать что да, он хочет этому приложений выдать свой емейл, а с другой - на этапе принятия приложения мы определяем для каких целей будет использоваться e-mail адрес.
Когда ПРИЛОЖЕНИЕ постит в личную ленту ПОЛЬЗОВАТЕЛЯ - это спам, и на ОК такое запрещено если пользователь явно не подтверждает данный пост.
Для бизнеса и автоматических публикаций - создаете группу, туда можете постить без подтверждения, и людям, заинтересованным группой, в ленту это событие тоже будет попадать.
Вообще если в виджет передать текущую сессию приложения (session_key или access_token), то в общем случае первого окна логина не будет и пройдет авторизация по сессии. Будет только подтверждение о публикации.
Ну да, этот пример кстати тоже не AS3 плагин использует, а подразумевает чо флеш подключен через iframe, где загружена fapi5 библиотека интеграции, и это вызов javascript метода, который поддерживает этот параметр
Если у вас есть возможность использовать js вызовы - это решит проблему. Если нет - используем виджет, указанный выше
Anuar12: политика ОК заключается в том, что все посты должны быть с согласия пользователя, поэтому данный метод и пермиссия считаются устаревшими и не выдаются. Есть альтернативное решение через предложеный виджет.
Альтернативный вариант - публиковать в группу, тогда достаточно GROUP_ACCESS, который получить можно
Ну данные это и есть строка, в конечном итоге объект же все равно засериализуется в строку и это представление может быть нежелательным (например, дроби неверно переведутся - с учетом текущей локали, а не по стандарту), что плохого в ручном приведении типов?
nobilik: Нет, есть вероятность что часть элементов будет пропущена, и вполне может быть, например, 98 или 99 элементов. Просто на первом чанке заментнее потому что на него накладываются дополнительные фильтры.
Общий принцип - клиент указывает ограничение о числе записей, сервис отвечает не большим числом записей, чем было запрошено и дает пометку, есть ли дальше еще доступные записи.
Есть пример без редиректа главной страницы при авторизации через html5 postmessage : https://github.com/odnoklassniki/ok-js-sdk/blob/ma...