Если окно входа открылось, но сайт после авторизации продолжает ждать, проверьте связь между окнами. Заголовок Cross-Origin-Opener-Policy (COOP) может разорвать её: страница провайдера загрузится, а приложение не получит результат.
Начните с ответов документов в основном и всплывающем окне, затем проверьте способ открытия и обработчик результата. Не отключайте защиту целиком: сначала подтвердите, на каком переходе пропадает связь.
1. Отделите сбой входа от предупреждения в Console
На тестовом аккаунте воспроизведите путь от нажатия кнопки до возвращения на сайт. Запишите браузер и его версию, момент сбоя и последнее изменение приложения, CDN или заголовков.
Отметьте, что произошло:
- окно вообще не появилось;
- окно открылось, но осталось пустым;
- выбор аккаунта завершился, а основная вкладка продолжает ждать;
- вход состоялся, хотя Console показывает предупреждение.
Сообщение о блокировке обращения к window.closed или postMessage — повод проверить сценарий, но ещё не доказательство его отказа. Если вход завершился, не меняйте политику только ради исчезновения сообщения; сверьте также, относится ли оно к Report-Only.
2. Сравните COOP у документов обоих окон
В DevTools откройте Network, включите сохранение журнала и повторите вход. Для всплывающего окна потребуется его собственный DevTools. Смотрите запросы типа Document: страницу с кнопкой, документы провайдера и страницу возврата на ваш сайт.
Для каждого запишите безопасный URL без параметров авторизации, origin и заголовки ответа. Origin — сочетание схемы, хоста и порта; соседний поддомен тоже может быть другим origin.
Cross-Origin-Opener-Policy: same-origin изолирует несовместимые документы и может разорвать ссылки между окнами. Решение зависит от политик обеих сторон и способа перехода, поэтому одного заголовка главной страницы недостаточно. Механизм описан в справочнике COOP.
Проверьте, кто добавил политику: приложение, веб-сервер, reverse proxy или CDN. Сопоставьте фактический ответ браузеру с конфигурацией; не ограничивайтесь поиском строки в коде. Отдельно различайте применяемый Cross-Origin-Opener-Policy и диагностический Cross-Origin-Opener-Policy-Report-Only.
Когда проверять same-origin-allow-popups
Для страницы, которая сама открывает доверенный внешний сервис, возможен вариант:
Cross-Origin-Opener-Policy: same-origin-allow-popupsОн позволяет сохранить связь с открываемым через window.open() документом, если у того политика unsafe-none, в том числе при отсутствии COOP. Это условие совместимости, а не универсальная починка любого OAuth.
Сверьте режим используемой библиотеки. Например, документация Google Identity Services различает обычные popup и FedCM: когда окно рисует браузер через FedCM, менять COOP для этого не требуется.
3. Исключите другие причины потери связи
На своей странице возврата разработчик может проверить, существует ли window.opener. Значение null само по себе не доказывает конфликт COOP: ссылку также убирают rel="noopener", параметр noopener при открытии окна и некоторые способы открытия ссылки. Эти случаи перечислены в описании window.opener.
Не убирайте noopener у всех внешних ссылок. Найдите конкретный вызов, которым библиотека открывает вход, и сопоставьте его с её документацией.
Если ссылка на окно сохранена, проверьте обработчик результата. При передаче через postMessage отправитель должен указывать точный targetOrigin, а получатель — проверять ожидаемые event.origin, event.source и формат сообщения. Не заменяйте адрес на *, чтобы скрыть несовпадение: правила приведены в документации postMessage.
Если сообщение дошло, но сессия не появилась, продолжайте проверку серверного завершения входа и Cookie. Потеря сессии после возврата разобрана отдельно в материале о SameSite. Если браузер блокирует загрузку ресурса, используйте разбор ERR_BLOCKED_BY_RESPONSE: это другая диагностическая ветка.
4. Подтвердите исправление полным сценарием
Сначала проверьте изменение на стенде с тем же способом входа и заголовками, что в production. Меняйте одно правило за раз и сохраните возможность отката.
Не ослабляйте COOP без проверки зависимостей: если приложению нужна cross-origin isolation, например для SharedArrayBuffer, изменение политики может нарушить её. В такой архитектуре разработчику следует оценить поддерживаемый библиотекой вход через перенаправление основной вкладки.
Критерий приёмки — не закрывшееся окно, а завершённый вход: приложение получило результат, сервер создал ожидаемую сессию, защищённая страница открывается после перезагрузки. Проверьте также отмену входа и повторную попытку: интерфейс должен прекращать ожидание и позволять начать заново.
Web-Puls может контролировать доступность публичного URL, но HTTP-проверка не воспроизводит OAuth popup и обмен сообщениями между окнами. Для этого нужен отдельный браузерный сценарий.
Если источник заголовка или место обрыва неясны, отправьте заявку на диагностику. Укажите адрес страницы входа, браузер, этап сбоя, безопасные значения COOP и последние изменения; пароли, Cookie, коды авторизации и токены не прикладывайте.