Использование параметра запроса url с контроллером

Question

Использование параметра запроса url с контроллером

Я пытаюсь реализовать oembed провайдер, использующий платформу Silverstripe, но столкнулся с проблемой.

У меня есть контроллер, перенаправленный с URL /omebed.json, и он работает нормально, если я вызываю что-то вроде /omebed.json?mediaurl=mymovie.mp4.
Однако в стандарте Oembed должно быть указано /omebed.json?url=mymovie.mp4

Но Silverstripe внутренне проверяет переменную $ _GET [‘url’] и пытается выполнить маршрутизацию на эту страницу / контроллер.
Поэтому SilverStripe пытается перенаправить на /mymovie.mp4, пропустив мой контроллер и нажав ErrorPage_Controller, создав 404.

Я думаю, что мне придется расширить ErrorPage_Controller и перенастроить его, если URL-адрес oembed.json, но это кажется немного хакерским.

Какие-либо предложения?

ура

2

oembed php silverstripe

Решение

Другие решения

У меня была быстрая игра с этим на днях. И смотря на что main.php Является ли может быть лучше покончить с этим, чем ErrorPage_controller,

Для начала SS по умолчанию .htaccess Файл делает это:

<IfModule mod_rewrite.c>
SetEnv HTTP_MOD_REWRITE On
RewriteEngine On
# RewriteBase /silverstripe

RewriteCond %{REQUEST_URI} ^(.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* framework/main.php?url=%1&%{QUERY_STRING} [L]
</IfModule>

Обратите внимание ?url изменив это на что-то другое, а затем меняя main.phpИспользование также может / должно помочь или вызовет кучу дополнительных ошибок и печали.

Чтобы избежать взлома ядра / фреймворка, вы можете изменить .htaccess, чтобы указать на копию main.php в mysite (с соответствующими включенными изменениями).

1

Источник

Accepted Answer

Продолжая ответ @ Стивена, вот способ обойти эту проблему без дублирования main.php и не изменяя его напрямую.

То, что я сделал, было создать _ss_environment.php файл который добавляется в начале процесса загрузки Silverstripe.

_ss_environment.php

global $url;
$url = $_GET['raw_url'];
if (isset($_GET['url']))
{
unset($_GET['url']);
}

// IIS includes get variables in url
$i = strpos($url, '?');
if($i !== false)
{
$url = substr($url, 0, $i);
}

.Htaccess

RewriteCond %{REQUEST_URI} ^(.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !\.php$
RewriteRule .* framework/main.php?raw_url=%1 [QSA]

Итак, вот что происходит:

.htaccess сейчас использует raw_url вместо url
_ss_environment.php вызывается в начале процесса загрузки, устанавливая Глобальный $url переменная, которая main.php обычно устанавливает. Это установлено с raw_url скорее, чем url,
Предотвращать main.php просто переопределить его снова, когда он видит ваш url параметр строки запроса, он не установлен (Silverstripe, кажется, сбрасывает это позже, насколько это касается моего теста).
Наконец, небольшой блок кода, который main.php будет нормально работать, если $_GET['url'] установлено, скопировано как есть для очевидной поддержки в IIS. (Если вы не используете IIS, вам, вероятно, это не понадобится.)

Это имеет несколько преимуществ:

Нет обновления для main.php позволяет немного улучшить Silverstripe в будущем
Запускает минимальный объем кода, необходимый для того, чтобы «обмануть» Silverstripe, думая, что он работает нормально.

Один очевидный недостаток любого решения для изменения формы url Параметр строки запроса, если что-либо смотрит на параметр напрямую. С тем, как работает Silverstripe, более вероятно, что код использует $url глобальная переменная или Director учебный класс вместо того, чтобы смотреть на строку запроса для текущего URL.

Я проверил это на сайте 3.1, выполнив упомянутые изменения и:

Создание контроллера называется TestController
в init Функция контроллера, я запускаю следующее:
```
var_dump($_GET['url']);
var_dump($this->getRequest()->getVars());
```
Посещенные /TestController?url=abc123увидел, что значение обоих дампов имеет значение «abc123» в качестве значения параметра URL.
Перейдите на несколько других пользовательских страниц на сайте, чтобы убедиться, что они все еще работают (никаких проблем, которые я видел)

К сожалению, я не смог найти документацию для порядка включения в отношении _config.php а также _ss_environment.php, Тем не менее, после просмотра кода, я решил, что это:

main.php работает, первая главная задача — это потребовать core/Constants.php
Constants.phpПервой задачей является поиск _ss_environment.php в базовой папке и потенциальных родительских папках. Если он найдет его, он будет включен.
Возвращаясь к main.php (а также после $_GET['url'] проверка сделана в main.php), он начнет ErrorControlChain который это внутренне требует другого для core/Core.php
внутри Core.php, он выполняет вызовы для манифеста конфигурации
ConfigManifest.php выставляет функции на самом деле добавить _config.php файлы и для них требуется.

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

3