Могу ли я разместить http psw на сайте и позволить Facebook REALTIME apis через?

Question

Я работаю над сайтом, который использует аутентификацию Facebook и друзей, но я не готов сделать его публичным. Похоже, если я введу пароль в каталог сайта, вызовы Facebook на мой сервер не смогут войти. Есть ли способ предоставить FB учетные данные пользователя / psw для сайта - просто обычная проверка подлинности http или что-то в этом роде? Сравнимо, наверное, - так что он сможет войти?

РЕДАКТИРОВАТЬ НА ОСНОВЕ УТОЧНЕНИЯ И БОЛЬШЕ ЭКСПЕРИМЕНТАЦИИ:

Есть две части:

• Нет проблем с Facebook Connect. Когда пользователь заходит на страницу защищенного сайта, ему предоставляется панель аутентификации, а затем он проходит аутентификацию (или нет). Если они это получают, соединение / вход в систему следует, и все хорошо, так как информация о соединении предположительно возвращается по тому же HTTP-соединению, которое только что было аутентифицировано. (Я немного запутался в этих частях работы http, но я думаю, что это в основном правильно.)

РЕАЛЬНАЯ проблема, с которой я сталкиваюсь, как я только что понял (извините, рано утром в понедельник / длинные выходные), это то, как поступают вызовы из API реального времени. Эти вызовы просто как бы поступают неожиданно, и поэтому есть нет аутентифицированного пути к серверу. Идея @ Марти о проведении аутентификации (опубликованной в более ранней версии вопроса) на основе IP-адреса выглядит многообещающей, но я все еще задаюсь вопросом, есть ли способ заставить FB отправлять пользователя / psw вместе с этим.

Answer 1

Просто сделайте исключение для сканера Facebook - вам не обязательно возвращать весь контент сканеру, только метатеги

Пользовательский агент: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)

{edit} почему бы просто не исключить URL обратного вызова, который вы используете для API реального времени, из вашей системы аутентификации?Других причин для доступа к этому URL не будет, и, вероятно, у вас нет такого контента, который мог бы видеть обычный пользователь, поскольку все, что делает обратный вызов, - это расшифровывают информацию из Facebook и обрабатывают ее {edit}

Answer 2

Альтернативой может быть использование аутентификации на основе IP-адресов.Разрешив только свой адрес и адрес Facebook, вы запретите другим пользователям доступ к сайту, но при этом разрешите приходить любые обратные вызовы из Facebook.

В ответ на обновленный вопрос : если это возможночтобы добавить базовую аутентификацию HTTP к URL-адресу обратного вызова (т. е. http://USER:PASSWORD@example.com/), вам нужно будет сделать это, добавив имя пользователя и пароль непосредственно к параметру callback_url при создании подписки в реальном времени .Однако то, будет ли это работать, зависит от того, сможет ли Facebook проанализировать ваш URL-адрес обратного вызова и правильно использовать обычную аутентификацию при взаимодействии с вашим сервером.

Answer 3

Вот, я думаю, правильный способ сделать это (возможно, это то, на что @Igy ссылается выше):

<Directory /path/to/site>

## Set up the basic password protection                                                                                            
AuthType basic
AuthName YourAuth
AuthUserFile /path/to/auth/file
AuthGroupFile /path/to/group/file
require group YourGroup

# Handle both ALLOW and DENY directives
Order allow,deny

# Allow the facebook servers (sadly, we still have to guess/track the addresses)
Allow from 66.220
Allow from 69.171
Allow from 69.63

# "Satisfy any" means that any of the above techniques will work for access
# Thus, you get in if you have a password or if you are coming from one of the
# specified addresses                                             
Satisfy any

</Directory>

Пока все хорошо, в любом случае ...