Почему Firebase auth использует перенаправление «middleware» перед возвращением в мое приложение? - PullRequest
Новая
       18

Почему Firebase auth использует перенаправление «middleware» перед возвращением в мое приложение?

0 голосов
/ 31 декабря 2018

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

Я заметил, что Firebase Auth SDK не перенаправляет напрямую на конечную точку OAuth, а затем обратно.Вместо этого он перенаправляет на https://my-app.firebaseapp.com/__/auth/handler, который затем перенаправляет на конечную точку OAuth с самим собой в качестве обратного вызова, а затем обратно на мой запрошенный URL обратного вызова.

Таким образом, вместо: 

myapp.com
   ↓
accounts.google.com/o/oauth2/v2/auth
   ↓
myapp.com

Это происходит: 

myapp.com
   ↓
myapp.firebaseapp.com/__/auth/handler
   ↓
accounts.google.com/o/oauth2/v2/auth
   ↓
myapp.firebaseapp.com/__/auth/handler
   ↓
www.myapp.com

Я не смог найти нигде документации об этом API, но я думаю, что, возможно, это внутреннее промежуточное ПО для предотвращения CSRF, или, может быть, просто API, который выполняет тяжелую работу по закрытиюразрыв между различными API федеративной идентификации.

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

Итак, для чего используется конечная точка https://my-app.firebaseapp.com/__/auth/XXX, и есть ли какие-либо документы по ее использованию?

Ответы [ 2 ]

0 голосов
/ 02 января 2019

Это в основном для простоты использования и удобства.Вы просто используете один URL-адрес обратного вызова из белого списка для всех ваших поставщиков OAuth (установите только один URL-адрес перенаправления для всех ваших поставщиков OAuth).Вам не нужно беспокоиться о его размещении, поскольку Firebase Auth сделает это за вас.Теперь вы можете разместить свое приложение в нескольких доменах для производства, на локальном хосте для разработки и т. Д. Если они включены в белый список вашего проекта, вы можете войти в систему с любым поставщиком OAuth по вашему выбору.Вы можете добавлять и удалять домены из белого списка в одном месте в настройках вашего проекта.Обратите внимание, что некоторые поставщики OAuth в прошлом разрешали использовать только один URL-адрес обратного вызова.Это обошло бы это ограничение.

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

Обратите внимание также на поток перенаправления, он не передает код авторизации OAuth и т. Д. Обратно на веб-страницу через строку запроса URL,вместо этого он делает это через iframe postMessage.Таким образом, перенаправление на исходный URL будет иметь тот же URL, без изменений.Таким образом, вы можете начать с https://www.example.com/#login, а затем вернуться к тому же URL-адресу для завершения входа в систему.

Кроме того, он не требует кода на стороне сервера, как это обычно делается с экспресс-паспортом и т. Д.код тоже.

0 голосов
/ 01 января 2019

myapp.firebaseapp.com/__/auth/handler - это URL, который регистрирует ваших пользователей с помощью Firebase Authentication.

URL-адрес accounts.google.com/o/oauth2/v2/auth регистрирует вас в Google OAuth, но не в Firebase.

Этот поток одинаков для всех поставщиков OAuth2, которые поддерживает Firebase.Так что если вы войдете в Facebook, вы увидите firebase auth handler -> facebook oauth handler -> firebase auth handler.

...