Как использовать одно и то же приложение facebook для разных сайтов

Я разрабатываю небольшую CMS на PHP, и мы делаем интеграцию с социальными сетями.

Контент изменяется одним администратором, который имеет право на публикацию новостей, событий и т.д...

Я бы добавил эту функцию, когда администратор публикует что-то, что он уже разместил на стене Facebook. Я не очень хорошо знаком с facebook php SDK, и я немного смущен этим.

Если (приведите пример) 10 разных сайтов используют мою CMS, нужно ли мне создавать 10 разных приложений facebook? (предположим, что все 10 веб-сайтов находятся в разных доменах и на разных серверах)

Во-вторых, есть ли способ аутентификации только с помощью PHP (что-то вроде прямой отправки имени пользователя и пароля), чтобы пользователю не нужно было входить в систему на Facebook?

Благодарность


person ArtoAle    schedule 14.03.2011    source источник


Ответы (2)


Пожалуйста, прочитайте на http://developers.facebook.com/docs/.

Это действительно легко и просто, и хорошо объяснено.

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

Если у вас возникли какие-либо конкретные проблемы с реализацией, это правильное место.

Однако, чтобы ответить хотя бы на часть вашего вопроса:

Самым мощным инструментом при работе с приложениями facebook является Graph API.

Его принцип очень прост. Вы можете выполнять практически любые действия от имени любого пользователя или приложения. Сначала вы должны создать токен, который идентифицирует пользователя и соответствующие разрешения. Эти токены можно сделать «постоянными», чтобы вы могли выполнять фоновые задачи. Обычно они активны очень короткое время, поэтому вы можете выполнять действия во время взаимодействия с пользователем. В процессе создания токенов участвует пользователь, поэтому он/она должен подтвердить запрашиваемые вами привилегии.

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

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

Приложение:

@АртоАле

вы правы в том, что каждое приложение привязано ровно к одному домену. однако, как только вы получили действительный токен, не имеет значения, где или кто вы используете его в графическом API.

позвольте мне объяснить это немного:

это не имело бы смысла, поскольку это вы делаете запрос. нет такой вещи, как "откуда приходит запрос". конечно, есть информация заголовка «referer», но она может быть указана свободно и не используется ни в каком контексте этого.

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

Почему?

это гарантирует, что какой-нибудь плохой парень не сможет настроить веб-сайт в любом домене и позволить пользователю авторизовать приложение и получить токен доступа с ВАШИМ приложением.

поэтому этот параметр гарантирует, что пользователь и токен доступа будут перенаправлены обратно на ВАШ сайт, а не на другой плохой сайт.

но есть альтернатива. если вы используете поток управления для настольных приложений, вы не получаете токен доступа сразу после того, как пользователь был перенаправлен обратно. вы получаете временный SESSION-TOKEN, который вы можете ОБМЕНЯТЬ на токен доступа. этот обмен выполняется на стороне сервера через API REST и требует секрета вашего приложения. Таким образом, на этом этапе гарантируется, что именно ВЫ получите токен.

Этот метод можно использовать в любом домене или в случае настольных приложений вообще без домена.

Это цитата из документации facebook:

Чтобы преобразовать сеансы, отправьте запрос POST на https://graph.facebook.com/oauth/exchange_sessions со списком сессий, разделенных запятыми, которые вы хотите преобразовать:

curl client_id=your_app_id \ -F client_secret=your_app_secret \ -F session=2.DbavCpzL6Yc_XGEI0Ip9GA__.3600.1271649600-12345,2.aBdC... \ https://graph.facebook.com/oauth/exchange_sessions Ответ на запрос представляет собой массив токенов доступа OAuth в формате JSON в том же порядке, что и сеансы:

[ { "access_token": "...", "expires": 1271649600, }, ...]

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

Таким образом, вы должны указать свой ОДИН домен в качестве URL-адреса перенаправления. Этот домен используется совместно вашими веб-сайтами. там вы можете получить полностью действительный токен доступа и беспрепятственно перенаправить пользователя обратно на веб-сайт вашего конкретного проекта и передать токен доступа.

Таким образом, вы можете использовать традиционный простой процесс аутентификации, который, вероятно, также более перспективен.

Факт остается. После того, как токен доступа сгенерирован, вы можете выполнять любые действия из любого домена, нет никакой разницы, поскольку буквально нет «домена», откуда поступает запрос (см. выше).

кроме того, если вы хотите, чтобы работали некоторые приятные функции javascript, такие как поле для комментариев или кнопка «Нравится», вам необходимо настроить открывать теги графика правильно.

если у вас есть какие-то проблемы с реализацией или, как вы сказали, "ошибки домена", пожалуйста, опишите их более четко, укажите шаги, которые вы сделали, и, если возможно, сообщение об ошибке.

person The Surrican    schedule 14.03.2011
comment
Ok. Я должен был упомянуть о графическом API в своем ответе. Я предположил, что это неявно понято. Виноват. - person uncaught_exceptions; 14.03.2011
comment
По сути, вы можете работать с любым приложением на любом веб-сайте. Поправьте меня, если я ошибаюсь, я могу использовать одно и то же fb-приложение на любых веб-сайтах, если у меня есть действительный токен аутентификации? - person ArtoAle; 14.03.2011
comment
@ArtOle это правильно. только поток аутентификации javascript привязан к домену. но в качестве альтернативы вы можете использовать поток аутентификации на рабочем столе, он также работает через Интернет, но включает дополнительный запрос на стороне сервера. - person The Surrican; 15.03.2011
comment
некоторые функции приложений доступны только в том случае, если вы добавите теги og: с идентификатором приложения на свой веб-сайт, но вы можете сделать это на нескольких веб-сайтах. границ домена нет. - person The Surrican; 15.03.2011
comment
@ArtoAle: Не совсем так, приложения назначаются ОДНОМУ домену, если ваши веб-сайты являются поддоменами, тогда да, иначе вам нужны разные приложения. - person ifaour; 15.03.2011
comment
@JoeHopgartner: Извините, что не обновлял страницу около 1 часа, вы уверены в том, что говорите?! у нас была ошибка домена из-за этого - person ifaour; 15.03.2011
comment
Я уверен в том, что говорю, но, возможно, я недостаточно ясно выразился. я добавил более подробное объяснение к моему ответу. - person The Surrican; 15.03.2011
comment
Хорошо, я наконец решил реализовать свои сайты таким образом. При настройке веб-сайта я использую веб-сервис, размещенный на моем веб-сайте (подключенном к приложению fb), для получения токена постоянного доступа, который я храню в файле db. (локально для каждого веб-сайта), и я использую токен для любого вызова fb, который мне нужен :) - person ArtoAle; 15.03.2011

Возможно, вы захотите разбить свой вопрос на более мелкие понятные единицы. Очень сложно понять, к чему вы клоните.

Мое понимание вашей проблемы может быть минимальным, но вот...

1_ Нет, вы не создаете 10 разных приложений facebook. Создайте одно приложение facebook и сделайте его точкой входа в сервис. Чтобы все ваши CMS-сайты могли обращаться к этому одному сайту для взаимодействия с facebook. (Служебный уровень REST).

2_ API Facebook не поддерживает аутентификацию по имени пользователя и паролю. Они поддерживают только oauth2.0. Хотя Oauth не тривиален, но поскольку они предоставили для этого библиотеку, реализация аутентификации довольно тривиальна.

person uncaught_exceptions    schedule 14.03.2011
comment
да, это определенно грязно, извините за это. На самом деле мне действительно нужно тратить больше времени на чтение документации fb API =) - person ArtoAle; 14.03.2011