Это уже обсуждалось пару раз, но я в основном комментировал более ранние вопросы, поэтому позвольте мне записать все как правильный ответ для дальнейшего использования.

[перефразировано] Вход в Facebook для нескольких клиентов с помощью одного идентификатора приложения

У кого-нибудь есть направление для меня?

Возможно, вы не хотите этого делать.

На самом деле невозможно запустить одно простое приложение в нескольких разных доменах.

В качестве обходного пути только для нескольких доменов люди использовали разные домены для разных платформ — веб-сайт, вкладка страницы или приложение Canvas, а также мобильная альтернатива для Canvas — фактически не используя ни одну из этих платформ, кроме веб-сайта, что сделало приложение пригодным для использования на несколько доменов в качестве веб-приложения. Но с тех пор, как Facebook представил свой процесс проверки входа/разрешения¹, вы больше не можете этого делать — они ожидают, что вы представите реальную функциональность на всех платформах, которые вы настроили в своем приложении.

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

Но у этого есть несколько недостатков:

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

• Вы не сможете использовать JS SDK для запросов API на стороне клиента или даже просто встроить его для отображения любого из социальных плагинов FB, которым требуется идентификатор приложения — SDK проверяет, в каком домене он «работает», и нельзя обмануть, чтобы принять домен, который не указан в настройках приложения.

• Могут быть проблемы с конфиденциальностью. Преувеличенный пример: то, что я как пользователь приложения решил поделиться своими фотографиями или видео, которые у меня есть на Facebook, с вашим клиентом Our-Holy-Mother-of-Christ-Bakery.com, не обязательно означает, что я хочу поделиться ими с другим вашим клиентом, amateurs-doing-all-kinds-of-nasty-stuff.xxx, но если они поделился идентификатором приложения для входа в систему, я автоматически сделал бы это. Получайте удовольствие от написания Политики конфиденциальности (которая является обязательной, если вы используете функцию входа в FB, и FB также автоматически проверяет, есть ли она в вашем приложении) для этого сценария ;-)

• И, наконец, самое главное: все ваши клиенты будут «сидеть в одной лодке». Если один из них или, в свою очередь, пользователи их веб-сайта опубликуют спам через идентификатор вашего приложения, чтобы Facebook заблокировал его, вход в систему больше не будет работать для всех веб-сайтов вашего клиента. И если вы решите только тогда, что лучше настроить отдельное приложение для каждого из ваших клиентов, они больше не смогут узнавать своих существующих пользователей из-за идентификаторов пользователей. будучи на уровне приложения с тех пор, как был представлен API версии 2.0, поэтому, если пользователи вошли в это новое приложение, это приложение увидит совершенно другой идентификатор пользователя. (И полагаться на адрес электронной почты в качестве идентификатора тоже рискованно, потому что вы не получите его от API для каждого пользователя, например, если они зарегистрировались с помощью своего мобильного устройства.)

• Изменить: Плюс, информация о приложении/домене, как упомянул luschn в своем ответе.

¹ Да, процесс проверки усложнил настройку нескольких приложений для нескольких клиентов. Но для приложений, которые делают то же самое или используют одни и те же разрешения одинаковым образом, вы можете обратиться к ранее успешно проверенному идентификатору приложения, чтобы немного ускорить процесс. Кроме того, скриншоты того, как f.e. сообщения, сделанные через приложение, отображаются на временной шкале, и какие компоненты пользовательского интерфейса используются, а также скринкасты, которые вы включаете в свое представление, вероятно, могут использоваться практически без изменений.

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

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

Многие из них не определены, но я думаю, что для того, чтобы быть умным разработчиком, вам нужно создавать новые идентификаторы приложений для каждого проекта, который вам нужен для использования Facebook Connect. Просто мое мнение. Это также позволяет вам контролировать множество вещей.