ASP.NET междоменные куки и Facebook Connect - PullRequest
0 голосов
/ 20 июля 2010

У меня есть веб-сайт, который я интегрирую с Facebook (через FBML - JavaScript API).

Я настроил приложение на Facebook в обычном режиме, указав «Connect URL» в качестве домена моего сайта.

Однако в моем приложении несколько привязок в IIS для одного веб-сайта.

Например:

www.bar.com.au

foo.com.au

Домены совершенно разные, никакого отношения к имени вообще нет - поэтому правило в стиле регулярных выражений невозможно (т. Е. Базовый домен). Домены были сделаны разными из-за сочетания локализации и маркетинга. Имейте в виду, что эти домены встроены в уже работающий сайт, иными словами, я не могу изменить эту архитектуру.

Есть ли способ указать ОБА этих доменов в ONE настройках приложения Facebook для "Соединить URL"? Или мне придется создавать несколько приложений?

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

У меня на сайте около 7 привязок - поэтому я бы не стал создавать 7 отдельных приложений Facebook - потому что это означает поддержание 7 наборов пар ключ / секрет API в моем приложении.

альтернативный текст http://www.freeimagehosting.net/uploads/268b234e2f.png

Конечно, что происходит, когда я на foobar.com.au, cookie-файлы Facebook недоступны для домена.

А пока я попытаюсь создать несколько ApiKey - но я думаю, что у меня могут возникнуть проблемы. Мне нужно идти: «Если это домен, используйте этот ApiKey», то такая же логика при каждом вызове Graph API. Грязные вещи.

Так что я полагаю, что моя проблема / вопрос на самом деле не вызвана Facebook Connect, а по своей природе это HTTP-куки.

Как я могу легко получить доступ к этим файлам cookie в кросс-домене? Нужно ли мне настроить третий веб-сайт и направить туда всю логику cookie?

Ответы [ 3 ]

0 голосов
/ 20 июля 2010

Если вы хотите, чтобы *.foobar.com.au было разрешено, настройте базовый домен на foobar.com.au.

0 голосов
/ 27 июля 2010

В моей текущей ситуации таймфреймы не позволили мне принять правильное решение, и именно это @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, который обрабатывает аутентификацию из одного места (т. е. отдельной сети).сервис на отдельном домене).

0 голосов
/ 20 июля 2010

Не могли бы вы установить один из них в качестве своего сайта "Аутентификация Facebook" и направить туда весь трафик, связанный с аутентификацией FB, а затем использовать один из большого числа приемов межсайтовой связи, чтобы отправить токен оригиналуsite?

Другими словами, независимо от того, с какого сайта они пришли, вы будете использовать .foobar.com.au (например) в качестве URI перенаправления.Затем, когда они зайдут на этот сайт, когда вы заметите, что они пришли с сайта .foo.bar.com.au, вы перенаправите их туда, откуда они пришли, путем передачи токена доступа каким-либо междоменным способом (querystring, postи т. д.)

...