#javascript #angular #google-signin
#javascript #angular #вход в Google
Вопрос:
Я использовал вход в Google в своем проекте angular 9. Я использую js API для входа в Google. Выдает ошибку, файлы cookie не включены в текущей среде в режиме инкогнито Google Chrome, хотя на обычной вкладке Google Chrome они работают нормально. ниже приведены сведения об ошибке.
details: "Cookies are not enabled in current environment."
error: "idpiframe_initialization_failed"
Понимаю, что в режиме инкогнито по умолчанию сторонние файлы cookie отключены, но каково решение для этого? Я обнаружил, что другие сайты, использующие вход в Google, отлично работают в режиме инкогнито Google Chrome.
Комментарии:
1. В настоящее время я сталкиваюсь с такой же проблемой. Я обнаружил, что, например, вход в Google в NYTimes отлично работает на вкладке «инкогнито». Я взглянул на его внутренности и заметил, что он создает свои кнопки совсем не так, как я их создаю. В то время как я использую gapi (load, init, attachClickHandler), NYTimes создает свой собственный URL-адрес авторизации и помещает его на кнопку. Я экспериментировал с настройкой cookie_policy на ‘none’, но это не помогло. Не думаю, что это когда-либо сработает в режиме инкогнито, если вы не сделаете это в стиле NYTimes. Я оставляю вам возможность перепроектировать их исходный код.
Ответ №1:
Angular — это просто javascript в браузере. Таким образом, пользователь, загружающий приложение angular, получает кучу javascript с вашего сервера. Если этот сервер обрабатывает аутентификацию с помощью Google-api, то ваш пользователь взаимодействует только с вашим сервером (хотя и с перенаправлением для входа в Google).
Для этого процесса аутентификации не требуются сторонние файлы cookie.
Однако! Если ваша аутентификация обрабатывается непосредственно в браузере пользователя, ваше приложение не будет работать, если сторонние файлы cookie отключены (поскольку они находятся в режиме инкогнито).
Например, у меня есть приложение angular, которое я обслуживаю через страницы Github. Github обслуживает приложение, но больше ничего не делает. Поскольку мне нужно создать документ в GDrive пользователя, я выполняю аутентификацию и получаю доступ к их ресурсам из клиента javascript. Для безопасной работы пользователи my ap должны разрешить сторонние файлы cookie. На самом деле нет способа обойти это.
Если бы у меня был сервер для моего приложения, пользователь мог бы предоставить моему серверу разрешение на доступ к своему Google диску, и сторонние файлы cookie не требовались бы. В этот момент к GDrive пользователя обращается не клиент JavaScript интерфейса (приложение angular), а мой сервер.
Использование серверной части обеспечивает другой и, как правило, более безопасный процесс аутентификации. Однако для пользователя пользовательский интерфейс тот же. Вот почему в некоторых ситуациях пользователь должен разрешать сторонние файлы cookie, а в других — нет.
В общем, вы можете защитить сервер намного лучше, чем вы можете доверять системе / браузеру пользователя, чтобы быть в безопасности. Если вас беспокоит безопасность, вам действительно следует выполнять вызовы API с сервера, а не из браузера. Это также должно решить вашу проблему.
Ответ №2:
Вероятно, вы используете 'ux_mode': 'redirect' , который включает фреймы iframes и файлы cookie.
Попробуйте использовать popup режим.
PS. Вы упомянули «Другие сайты, которые отлично работают» — они, вероятно, используют поток аутентификации OAuth2 на стороне сервера, который основан на перенаправлениях.
PPS. Дополнительная информация https://developers.google.com/identity/sign-in/web/troubleshooting смотрите раздел «Известные проблемы»
Комментарии:
1. Нет, во всплывающем режиме такое же поведение
2. Это потому, что по умолчанию используется значение «всплывающее окно».
Ответ №3:
Простым решением может быть включение Block third-party cookies . перейдите на свою первую страницу в режиме инкогнито, вы можете увидеть внизу Block third-party cookies разворота, что из.
это решение работает, по крайней мере, для меня.
Комментарии:
1. Это не устраняет проблему на сайте, это просто заставляет его работать на компьютере OP. Это все равно было бы нарушено для всех остальных.
Ответ №4:
Если у кого-то возникли проблемы с входом в Google (в частности, с получением токена доступа) в режиме инкогнито, обратитесь к следующему примеру реализации в Next.js
export default function useGoogleLogin() {
useEffect(() => {
const matches = window.location.hash.match(/access_token=([^amp;]*)/);
if (!matches) {
return;
}
console.log('Access token', matches[1])
}, []);
const handleLogin = () => window.location.replace(getAuthUri());
return { handleLogin };
}
И вот реализация getAuthUri
export default function getAuthUri() {
let base = window.location.href,
state = "";
let i = base.indexOf("#");
if (i > -1) {
state = base.substring(i);
base = base.substring(0, i);
}
return (
"https://accounts.google.com/o/oauth2/v2/auth"
"?client_id="
encodeURIComponent(process.env.GOOGLE_CLIENT_ID)
"amp;redirect_uri="
encodeURIComponent(base)
"amp;state="
encodeURIComponent(btoa(state))
"amp;response_type="
encodeURIComponent("token")
"amp;scope="
encodeURIComponent("profile")
"amp;include_granted_scopes="
encodeURIComponent("true")
);
}
Ответ №5:
Управление сеансом необходимо выполнять, если мы хотим сохранить какие-либо данные в режиме инкогнито.
Spring Session предоставляет API и реализации для управления информацией о сеансе пользователя, а также упрощает поддержку кластеризованных сеансов без привязки к решению, зависящему от контейнера приложения. Он также обеспечивает прозрачную интеграцию с:
HttpSession: позволяет заменить HttpSession нейтральным для контейнера приложения способом с поддержкой предоставления идентификаторов сеанса в заголовках для работы с RESTful API.
WebSocket: предоставляет возможность поддерживать HttpSession активным при получении сообщений WebSocket
Веб-сессия: позволяет заменить веб-сессию Spring WebFlux нейтральным для контейнера приложения способом.