#authentication #oauth #firewall #google-calendar-api #intranet
#аутентификация #oauth #брандмауэр #google-calendar-api #интрасеть
Вопрос:
Я пытаюсь создать веб-приложение для добавления событий в календарь Google сотрудника и хотел бы использовать OAuth для аутентификации.
Однако мое веб-приложение вынуждено находиться в интрасети за брандмауэром; сервер имеет исходящий доступ в Интернет, но блокирует внутренний доступ, если вы не подключены к интрасети или не подключены по виртуальной сети к интрасети.
Я читаю об OAuth, но не могу понять, будет ли часть процесса подтверждения подлинности заблокирована моим брандмауэром. (И я хотел бы знать, возможно ли это, прежде чем тратить время на реализацию, если это невозможно; и знайте, что если я столкнусь с ошибками, я смогу их отладить).
Ответ №1:
Чтобы расширить ответ planetjones, пока Google может разрешить DNS для URL вашего приложения, oauth2 должен работать за брандмауэром. У нас возникли некоторые проблемы с получением oauth2, работающего за нашим брандмауэром, потому что мы пытались использовать неполное доменное имя.
Ответ №2:
OAuth должен отлично работать через http, используя POSTs и GET, и если ваш клиент может установить заголовок Authorizatioon. Клиент должен создавать все запросы, и пока он следует перенаправлениям, все должно быть в порядке — насколько мне известно, никогда не было случая, чтобы внешний сервер инициировал входящее соединение.
Для дополнительной уверенности попробуйте OAuth с помощью существующей сторонней службы из-за вашего брандмауэра, чтобы быть уверенным. Это выглядит как хорошая отправная точка, и это является окончательным руководством для следования потокам вызова OAuth.
Комментарии:
1. Обе ссылки разорваны.