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

Question

Я пытаюсь реализовать провайдера 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, но это кажется немного взломанным.

Любые предложения?

Приветствия

Answer 1

Расширение ответа @ Stephen, вот способ обойти эту проблему, не дублируя main.php и не изменяя ее напрямую.

Что я сделал, это создать _ss_environment.php file, который добавляется на ранней стадии процесса загрузки 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 вызывается в начале процесса загрузки, устанавливая global $url variable that main.php normally sets. Это устанавливается с raw_url, а не url.
• Чтобы предотвратить main.php, чтобы просто переопределить его снова, когда он видит ваш параметр строки запроса url, он не установлен (похоже, Silverstripe возвращает это позже, насколько это касается моего теста).
• Наконец-то это небольшой блок кода, который main.php would normally run if $_GET['url'] is set, скопирован как -является очевидной поддержкой в ​​IIS. (Если вы не используете IIS, вы, скорее всего, не нужно.)

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

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

Единственный очевидный недостаток любого решения для смены формы параметра строки запроса url - это если что-то напрямую смотрит на параметр. Как работает Silverstripe, более вероятно, что код использует глобальную переменную $url или Director class вместо того, чтобы смотреть на строку запроса для текущего 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 runs, first main task is to require core/Constants.php
• Constants.php's first task is to search for _ss_environment.php in the base folder and potential parent folders. Если он находит его, он будет включен.
• Возвращаясь к main.php (и после$_GET['url'] проверка делается в main.php), это запустит ErrorControlChain который it internally does another require for core/Core.php
• Inside Core.php, it performs calls for the config manifest
• ConfigManifest.php exposes the functions to actually add _config.php files and for them to be required.

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

Answer 2

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

Для startes файла 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 «S, а также может/должно помочь или вызовет кучу дополнительных ошибок и печаль.

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