Возможность блокировки redirect_uri для создания интранет-приложений - PullRequest
Новая
       22

Возможность блокировки redirect_uri для создания интранет-приложений

1 голос
/ 23 марта 2012

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

Для авторизации мне нужнопройти через поток (т. е. https://graph.facebook.com/oauth/authorize с параметрами client_id=1234567890 и redirect_uri=http://customer-intranet.example.com) - и это второе, что ставит меня в тупик, потому что я не могу предсказать redirect_uri, а Facebook, похоже, строго относится ко всемупредварительно указано в приложении.

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

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

1 Ответ

4 голосов
/ 12 мая 2012

Вы можете рассмотреть Аутентификация на стороне клиента flow или использование JS-SDK с OAuth Dialog , так что вы можете легко избежать указания redirect_uri, так как это может предоставляется автоматически JS-SDK (или вы можете использовать текущий URL window.location, как показано в документации по потоку аутентификации на стороне клиента).

Примечания:

Хотя это может помочь вам избежать использования redirect_uri, настоящая проблема немного глубже ...

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

Application Settings screenshot

Поэтому, как правило, вам нужно будет указать доменное имя redirect_uri / URL-приложения, работающего на , в настройках приложения, что неприятно для многих клиентов / доменов.

Вы можете реализовать поток аутентификации, используя отдельный (общедоступный) хост, но перед тем, как сделать это, полезно задать себе пару вопросов:

  1. Кто будет отвечать за этот хост и что произойдет со всеми вашими клиентами, если что-то пойдет не так с этим хостом только для аутентификации.
    • Это дополнительная зависимость, которую лучше избегать.
  2. Будете ли вы предоставлять домены всем своим клиентам в настройках приложения?
    • Это может привести к нарушению политик платформы при передаче данных третьим сторонам (предварительно проконсультируйтесь с юристом компании)
  3. Требуется ли вам использовать одно приложение для всех ваших клиентов?
    • Если нет, лучше проинструктировать клиентов о настройке приложения и настройке приложения / кода с учетными данными, которые они получили.

Подводя итог:
Вы можете создать отдельное приложение для каждого клиента или поручить клиенту настроить приложение как часть процесса установки / настройки для вашего приложения. Позже вы можете использовать поток аутентификации на стороне клиента для создания универсального кода, который будет работать для каждого клиента (это возможно и для потока на стороне сервера, но потребует некоторой дополнительной работы, а с JS-SDK FB.login это может быть функциональность раскрытия без дополнительной работы).

...