работа приложения внутри iframe

[AlekseiJK]

Доброго всем дня! Подскажите пожалуйста по следующей проблеме:

Есть SPA срендеренная на next.js
если я ее открываю просто как страницу то все работает, ежели я ее пихаю в айфрейм то ничего не работает в консоле ошибка

DOMException: Failed to execute 'replaceState' on 'History':
A history state object with URL 'http://localhost:63342/cdoc' cannot be created in a document
with origin 'http://localhost:63342' and URL
 'about:srcdoc'

из которой я понял что роутинг внутри айфрейма использует origin страницы на которой находится iframe в данном примере это "http://localhost:63342"
соответственно он пытается куда-то перейти добавляя в путь /cdoc, но у него естественно не получается потому что для перехода он должен использовать путь https://searchengine.com/cdoc

пытаюсь понять как правильно сконфигурировать iframe чтобы все работало, пока безуспешно, возможно нужно делать что-то с настройками CPS

страницу вставляю используя атрибут srcdoc
через src не получается потому что чтобы получить срендеренную страницу мне нужно отправить гет запрос с заголовками авторизации

атрибут sabdbox выглядит следующим образом

sandbox="allow-scripts allow-same-origin allow-forms allow-popups
 allow-modals allow-orientation-lock allow-pointer-lock allow-presentation
 allow-top-navigation"

[voraa]

Если iframe вставляется со страницы через srcdoc, то он будет иметь ориджин страницы. Ничего тут не сделать. Другого он не знает.

[MallSerg]

Ты хочешь обойти "политику одного источника"

Как конкретный пример объясняющий почему браузеры проводят такую политику. Представь что ты зашёл на любую страницу в интернете а на этой странице есть скрипт который создает ифреймы всех твоих социальных сетей и отправляет "гет запросы с заголовками авторизации" которые должны разослать всем твоим знакомым личные сообщения с как бы твоим сообщением о том как прекрасно увеличить необходимую часть тела в некоторой замечательной клинике xD.

Что бы такого не происходило браузеры разделяют интернет запросы в соответствии с их происхождением/источником/начальным_URL т.е.
источник localhost:63342 не может отправлять и обрабатывать запросы к searchengine.com если этого явно не разрешено источником к которому обращаются с запросом.

[AlekseiJK]

Получается мне нужно чтобы на стороне searchengine.com было разрешено обращаться с запросом?
А как это делается?

[ruslan_mart]

А что вы хотите сделать? Я открыл этот сайт, кажется, что это просто поисковая строка, которая редиректит на поиск в гугле.

Имейте ввиду, что гугл-поиск никак не получится затащить в iframe, у них запрет на открытие сайта в iframe.

[MallSerg]

Получается мне нужно чтобы на стороне searchengine.com было разрешено обращаться с запросом?
А как это делается?

Обращаться с запросом можно можно к любому ресурсу в интернете. В ответ на запрос по протоколу HTTP/HTTPS сервер может прислать ответ в этом ответе есть "служебные заголовки http" в которых может быть указано что полученный ресурс может быть использован другими доменами/источниками для своих целей. Контроль за соблюдением этой политики осуществляет браузер конечного пользователя.
подробнее https://developer.mozilla.org/ru/docs/Web/HTTP/CORS

т.е. Источник отправляет запрос, сервер его получает и принимает решение о необходимости выдачи разрешений и отправляет ответ с разрешениями (или не отправляет).

[voraa]

Тут даже проблема иногда не в том, что бы получить данные, а в том, что бы с ними потом работать.
Например мы всегда можем получить Image из другого источника. Мы можем вставить эту картинку в canvas. Но потом выполнить toDataURL из этого канвас не получится. Потому, что в нем картинка из другого источника.

[AlekseiJK]

А что вы хотите сделать? Я открыл этот сайт, кажется, что это просто поисковая строка, которая редиректит на поиск в гугле.

Имейте ввиду, что гугл-поиск никак не получится затащить в iframe, у них запрет на открытие сайта в iframe.

прошу прощения за путанницу, адрес фейковый, для примера

[AlekseiJK]

Итого что у меня получилось на данный момент:
Я получаю по апи отрендеренный сайт в виде строки
мне нужно его вывести в микрофронтенд на singl-spa
мое решение состоит из двух частей
1) бэкенд часть на спрингбуте (она берет на себя проверку прав пользователя, запрашивает срендеренную страничку у стороннего сервиса и выдает на фрон ее в виде строки либо в виде html страницы
2) фронтенд часть - на вью - встраивается в single-spa и отвечает за отправку запроса на бек с заголовками авторизации, получает ответ и пытается его обработать для отображения пользователю
проработав тему я для себя увидел следующие пути
- приложение на вью в котором будет iframe в который соответственно будет вставляться полученная мной страничка
- приложение на вью в которое будет вставляться страничка без iframe тупо как часть компонента
- сделать так чтобы каким-то образом single-spa не взаимодействовала с вью а напрямую скачивала и отображала страничку в качестве одного из своих микрофронтендов

с чем я столкнулся и не могу побороть
- если вставлять в iframe то только через атрибут srcdoc но тогда у встаиваемой странички меняется origin и скрипты которые в ней используются перестают правильно работать (например вместо того чтобы перейти по http://xxx.ru/abc они пытаются срутить на http://localhost/abc)
- если вставлять страницу в приложение как часть компонента, то вью оборачивает ее в свой динамический контекст и опять же скрипты на ней не работают
-через src не получается вставить, потому что нужно добавлять заголовки авторизации к гет запросу

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

что думаете ребят?