#asp.net #iis #cookies #facebook #cross-domain
#asp.net #iis #файлы cookie #Facebook #междоменный
Вопрос:
У меня есть веб-сайт, который я интегрирую с Facebook (через FBML — JavaScript API).
Я настроил приложение на Facebook в обычном режиме, указав «URL подключения» в качестве домена моего веб-сайта.
Однако мое приложение имеет несколько привязок в IIS для одного и того же веб-сайта.
Такие как:
www.bar.com.au
foo.com.au
Домены совершенно разные, в названии нет никакой связи вообще — поэтому правило в стиле регулярных выражений невозможно (т.Е. базовый домен). Домены были сделаны разными из-за сочетания локализации и маркетинга. Имейте в виду, что эти домены подключены к уже действующему веб-сайту, другими словами, я не могу изменить эту архитектуру.
Есть ли способ указать ОБА этих домена в настройках приложения ONE Facebook для «URL подключения»? Или мне придется создавать несколько приложений?
Конечно, я не могу использовать параметр «Базовый домен», поскольку привязки находятся не в одном поддомене.
На самом деле у меня на моем веб-сайте около 7 привязок, поэтому я бы предпочел не создавать 7 отдельных приложений Facebook, потому что это означает поддержание 7 наборов пар API key / secret в моем приложении.
альтернативный текст http://www.freeimagehosting.net/uploads/268b234e2f.png
Что происходит, конечно, когда я на foobar.com.au файлы cookie Facebook недоступны для домена.
Тем временем я попытаюсь создать несколько APIKEY’ов, но, думаю, у меня могут возникнуть проблемы. Мне придется сказать: «Если домен этот, используйте этот ApiKey», затем та же логика в каждом отдельном вызове Graph API. Грязный материал.
Так что я предполагаю, что моя проблема / вопрос на самом деле вызван не Facebook Connect, а природой HTTP Cookies по дизайну.
Как я могу легко получить доступ к этим файлам cookie из разных доменов? Нужно ли мне настраивать третий веб-сайт и направлять всю логику файлов cookie туда?
Ответ №1:
Если вы хотите, *.foobar.com.au чтобы они были разрешены, затем настройте свой базовый домен на foobar.com.au .
Комментарии:
1. Отредактированный вопрос — домен не всегда содержит Foobar. Вот что происходит, когда вы «перегружаете» код, смехотворно.
2. Могу я спросить, каков ваш вариант использования для нескольких базовых доменов?
3. У нас есть несколько версий нашего веб-сайта для разных языков. Итак, в Австралии наш домен может быть australia.foo.bar.com и в Америке это может быть www.foobar.com. Не собираюсь рисковать этими доменами — они были проданы таким образом, поэтому не могу изменить их сейчас.
Ответ №2:
Не могли бы вы настроить один из них в качестве своего сайта «Facebook Authentication» и направлять туда весь трафик, связанный с FB Auth, а затем использовать один из большого количества способов межсайтовой связи для отправки токена на исходный сайт?
Другими словами, независимо от того, с какого сайта они поступают, вы будете использовать .foobar.com.au (например) в качестве URI перенаправления. Затем, когда они заходят на этот сайт, вы отмечаете, что они пришли с .foo.bar.com.au вы перенаправите их обратно туда, откуда они пришли, передавая токен доступа некоторым междоменным способом (строка запроса, переменные post и т.д.)
Комментарии:
1. Не могли бы вы пояснить, пожалуйста? Также обратите внимание, что я использую JavaScript API для аутентификации, поэтому мне нужен доступ к файлам cookie в домене.
2. да .. я тоже действительно смущен этим ответом. Не могли бы вы, пожалуйста, пояснить, что вы имеете в виду? В чем хитрости межсайтового взаимодействия ?
3. Приемы межсайтовой связи включают в себя использование какого-либо механизма для передачи данных с одного сайта на другой, что, как предполагается, усложняет политика одного и того же источника. Одним из методов является межсайтовый запрос POST (он же отправка формы). Другим является перенаправление с токеном доступа в строке запроса.
4. Спасибо за разъяснение. Я понимаю, о чем вы сейчас говорите. На самом деле, вероятно, лучше всего настроить независимый сервер авторизации (веб-службу ie). На самом деле это невозможно для тех временных рамок, которые у меня есть на данный момент. Я действительно не хочу передавать запросы querystring / post между серверами, потому что это добавляет зависимость от одного из серверов, где на самом деле это не работа сервера. Спасибо за советы — я рассмотрю лучшее решение, когда мы обновим проект (что произойдет в ближайшее время). На данный момент я просто собираюсь использовать несколько ключей api / logic smarts.
Ответ №3:
В моей текущей ситуации временные рамки помешали мне найти правильное решение, на что и обратил внимание @Yuliy.
На данный момент я создал несколько приложений Facebook. Но чтобы сохранить это СУХИМ, я абстрагировал все это за открытыми свойствами:
private static string _ApiToken_Site1, _ApiToken_Site2;
public static string ApiToken
{
get
{
if (Site1) return _ApiToken_Site1;
else if (Site2) return _ApiToken_Site2;
}
}
Не совсем чисто, но главное, мне вообще не нужно было трогать мой существующий код, достаточно ума, чтобы определить, какой ключ API использовать, в этом свойстве.
Для нашего следующего выпуска проекта я откажусь от этого и, скорее всего, внедрю веб-службу WCF / ASMX, которая обрабатывает аутентификацию из одного места (т. Е. отдельную веб-службу в отдельном домене).