это делает сайт более уязвимым к XSS атакам.Нет, скорее это наносит больший ущерб в случае удачной атаки, к самой защите от атак это никак не относится.
Так что же лучше, устанавливать куки стороне клиента или сервере?Что лучше, мягкое или теплое? Разные куки подходят для разных задач. Если речь все еще про токены и авторизацию - только бэкенд.
По началу я устанавливал куки и помещал в них токен на стороне бекенда, так-же удалял куки, с этим способом возникли некоторые проблемы.Некоторые проблемы очевидно решаются, судя по тому что миллионы программистов с этим как-то справляются. Очевидно надо искать как решаются типовые задачи вместо поиска черных костылей в темной комнате.
не работает эта часть кодаНормально описывайте что происходит, "не работает" это не описание проблемы, что пишет консоль, какие ошибки? Описывайте в вопросе.
Как мне их правильно соединить?Во первых - зачем? Смысл разноса api и приложения в том что бэк работает одинаково со всеми запросами (не особо важно кто и как их дергает, лишь бы права позволяли), а фронт не зависит от бэка в представлении. По этому фронт пишется как морда на каком-нибудь реакте, который от бэкенда получает данные по запросу. Нужно авторизоваться - стучишся в эндпоинт авторизации, отдаешь креденшелы, получаешь токен. Нужно список юзеров - берешь доку по апи, стучишся с нужным пэйлоадом на эндпоинт, получаешь жсон списка, из него рисуешь что хочешь...
Или frontend и backend размещены разными программами?что-то мне подсказывает что наверное вы рановато по знаниям взялись за задачу...
src="/static/img.png" и src="/templates/img.png"
И заметила, что основная часть задач - инфраструктурная.Такой работы всегда много, но есть нюансы.
Настройка тестовДа, это в любой разработке будет, не только во фронте
CI/CDСомнительно, но окэй, знать это очень желательно, но в крупных проектах этим занимается девопс, как минимум настраивает скрипты. В малых компаниях это раскидывается на разрабов, есть такая практика.
OLAP CUBE, оптимизация запросов к БД.А это вообще чисто бэкендерские заморочки, конечно никто бить за понимание таких штук не будет, но в целом фронту это не особо важно, у него должно быть расписано апи/эндпоинты и чего туда пихать и что получать. Уж оптимизацией запросов чистый фронтендер точно не обязан заниматься.
Насколько известно, REST не хранит состояние клиента между запросам.Это не значит что он вообще не хранит состояние клиента, это значит что он хранит только состояние на момент синхронизации, а МЕЖУ запросами состояние клиента находится в неопределенном состоянии до момента следующей синхронизации. То есть это не принцип который надо соблюдать, а констатация факта. Кроме того, в вашем примере бэкенду/апи вообще должно быть фиолетово на состояние клиента.
Клиент передаёт необходимые данные в первом запросе. Эти данные меняют состояние сущности (лабиринт) на сервере.Сущность лабиринт НИКАК не затрагивается, у вас может изменяться только принадлежащие вам сущности, в данном примере у вас будет меняться состояние робота.
Если бы клиент располагал всеми данными,то он был бы бэкендом и апи было бы не нужно. Собственно апи - способ обмена запрашиваемыми данными.
Последующие запрос-ответы связаны с предыдущими, не имеют смысла без выполнения предыдущих, поскольку сервер хранит изменяемую сущность (лабиринт).Не лабиринт.
Как серию "запрос-ответ" логически объединить?Зависит. Так как вопрос у вас на пальцах и вообще без конкретики, то и ответ будет достаточно общим в рамках описанной системы.
GET someapi.tld/api/v1/robot/{id}, в результате назад вы получите объект робота с координатами. Что с ними делать зависит от вашего функционала, например можно задать новые целевые координаты.
if(!$_GET["request"] || typeof $_GET["request"] !== 'string')typeof здесь не в тему, так как у вас ВСЕГДА приходит стринг, в гет запросе (как впрочем и в любом другом) нельзя указать тип.
1. Есть ли лучшие идеи, чем мои?В принципе идея не нова, есть даже сервисы готовые под похожие задачи, типа cors-anywhere от heroku и еще куча по запросу cors proxy.
Я понимаю, что можно напрямую делать запрос к '/?request=''" и не заморачиваться с .htaccess, но такой вариант не красив.Это вообще 2 разные задачи. .htaccess настраивается на единую точку входа как написал Сергей delphinpro, далее вы в коде все запросы прошедшие к индексу проверяете на $_SERVER['REQUEST_URI'] (никакой /?request вам не нужен), вытаскиваете из него урл картинки и уже например curl используете для получения ее с другого сайта. Картинку запросу отдать как текст, предварительно отослав соответствующие картинке заголовки.
2. Как лучше всего обработать ошибку и сделать перенаправление при ненужном или неправильном запросе?проверять $_SERVER['REQUEST_URI'] на "правильность", например что запрашивается файл определенных заранее типов, ака вайтлист. В случае несовпадения можно тупо отправить 404.
3. Как обеспечить безопасность субдомена?Безопасность от чего?
if(!file_exists(folder)) { // проверка на существование папки / файла (так папки или файла?)
CreateFolder(folder, req) //а если это файл, все равно создаем папку с таким именем?
return //то есть вложенность больше 1 уровня папки создаваться не будут?
}