Во-первых, получение символики для Facebook из окружающей среды на самом деле не очень хорошая идея. Если то, что вы хотите сделать, это получить сообщения для пользователя, токен должен быть токеном пользователя (в отличие от более ограниченного токена приложения). То, как вы получаете этот токен, - это запустить пользователя через поток полномочий, предлагаемый ConnectController от Spring Social. Этот поток требует от пользователя не менее в Facebook и авторизации приложения. Независимо от того, подписываются ли они на ваше приложение, зависит от пользователя.
(Обратите внимание, что это также верно для Твиттера, хотя токены доступа Twitter не истекают. Поскольку они не истекают, вы можете получить доступ к токену другими способами, а затем жестко закодировать его в своей конфигурации На самом деле это не так, как это предполагается использовать, но это будет работать.)
Типичный поток состоит в том, чтобы пользователь входил в ваше приложение (либо непосредственно через какую-либо страницу входа в приложение, либо косвенно через Facebook, Twitter и т. Д.). а затем работать через поток ConnectController для получения авторизации (и, следовательно, токена доступа). В типичном потоке вы напрямую не создаете экземпляры FacebookTemplate или TwitterTemplate - они создаются для вас через Connection (который представляет собой авторизацию, полученную ConnectController).
Чтобы справиться с истекшими токенами, Spring Social также предлагает ReconnectFilter, который пытается восстановить соединение (возвращаясь через ConnectController), если обнаруживает, что по какой-либо причине токен доступа больше недействителен. Хотя это означает, что браузер пользователя будет перенаправлен на Facebook и обратно, перенаправление будет незаметно для пользователя до тех пор, пока авторизация все еще действительна (токены истекают, авторизации нет). Если авторизация все еще действительна, Facebook будет перенаправлять обратно без запроса пользователя для авторизации.
Если вы являетесь пользователем, то вы могли бы обойти проверку подлинности в приложение, настроить UserIdSource, который всегда возвращает один и тот же идентификатор (что вы хотите, чтобы это было), а затем разрешение будет связан с этим идентификатором. Но вам все равно нужно пройти через поток авторизации, чтобы получить токен доступа.
Это означает, что вы можете получить токен доступа с помощью других средств и выполнить его жесткое кодирование в своей конфигурации, но, как вы указали, токен истекает, а затем конфигурация больше не будет работать.
Лучший пример, который я могу указать, - https://github.com/spring-projects/spring-social-samples/tree/master/spring-social-showcase-boot.Конечно, он поддерживает аутентификацию (как напрямую, так и на основе провайдера), но он демонстрирует типичный поток для получения экземпляра FacebookTemplate или TwitterTemplate, который включает в себя получение авторизации пользователя. Вы увидите, что очень небольшая конфигурация Spring Social (фактически, очень маленькая конфигурация любого типа), потому что она использует автоматическую конфигурацию Spring Boot. Если вы хотите использовать более явный пример конфигурации, посмотрите на https://github.com/spring-projects/spring-social-samples/tree/master/spring-social-showcase, который не использует Spring Boot.
(ИМО, вы должны благоприятствовать с помощью Spring бутсу, хотя.)
Это часть моего веб-приложение, которое показывает альбомы моей странице facebook. Я не знаю, почему необходимо иметь токен доступа для получения этой информации, поскольку она является общедоступной. Какая альтернатива этому материалу Jdbc? Я не хочу иметь репозиторий соединений. – dtrunk
Конфигурация слишком сложна, чтобы просто работать с Graph API. – dtrunk
Теперь я использовал токен доступа к приложениям. Это позволяет мне делать это без репозитория jdbc и других объектов, которые мне не нужны. – dtrunk