컨트롤러에 url 쿼리 매개 변수 사용

Question

Silverstripe 프레임 워크를 사용하여 oembed 공급자를 구현하려고하지만 문제가 발생했습니다.

url /omebed.json에서 라우트 된 컨트롤러가 있고 /omebed.json?mediaurl=mymovie.mp4와 같은 것을 호출하면 정상적으로 작동합니다.
에서 oEmbed 표준이 /omebed.json?url=mymovie.mp4

해야하지만 Silverstripe 내부적으로 $ _GET [ 'URL'] 변수를 확인하고 해당 페이지/컨트롤러 노선에 시도합니다 상태 그러나. 그래서 SilverStripe는 URL이 oembed.json 경우 ErrorPage_Controller을 확장하고 rejig해야하는가는 404

내가 생각하고 메신저를 만드는 ErrorPage_Controller을 내 컨트롤러를 건너 뛰는 타격 /mymovie.mp4하는 경로에 노력하고있다 그러나 이것은 약간 hackish 보인다.

제안 사항?

건배

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을 지금을 사용하고 있습니다 10 대신 url
• _ss_environment.php이로드 프로세스 초기에 global $url variable that main.php normally sets으로 설정되어 있습니다. 이 값은 url이 아니라 raw_url으로 설정됩니다.
• url 쿼리 문자열 매개 변수를 볼 때 main.php이 다시 덮어 쓰지 않도록하려면 설정이 해제되어 있습니다 (Silverstripe는 나중에 내 테스트와 관련하여 초기화됩니다).
• 마지막으로 IIS의 명백한 지원을 위해 복사 된 main.php would normally run if $_GET['url'] is set 코드의 작은 블록이 있습니다. (IIS를 사용하지 않는 경우, 당신은 가능성이 필요하지 않습니다.)

이 몇 가지 이점이 있습니다

main.php에 어떤 업데이트가 미래 약간 쉽게 Silverstripe를 업그레이드하지 않습니다 허용
• Silverstripe이 정상적으로 실행되고 있다고 생각하도록 "속이기"위해 필요한 최소한의 코드를 실행합니다.

url 쿼리 문자열 매개 변수에서 벗어난 변경 솔루션의 한 가지 명백한 단점은 매개 변수를 직접 보는 경우입니다. Silverstripe 작동 방식을 사용하면 코드에서 $url 전역 변수를 사용하거나 Director class을 사용하는 것이 현재 URL의 쿼리 문자열을 보는 것이 아닙니다.

는 나는 내가 언급 한 변화와 수행하여 3.1 사이트에서이 테스트 : 컨트롤러의 init 기능에서 불리는 컨트롤러 TestController

만들기

• 을, 나는 다음을 실행하고 :

  var_dump($_GET['url']); 
  var_dump($this->getRequest()->getVars()); 
  

• 방문한 /TestController?url=abc123, 두 덤프의 값은 URL 매개 변수의 값으로 "abc123"을가집니다.
• 은 여전히 ​​(내가 본 어떤 문제가) 작동되지 않았다 확인

---

불행하게도, 내가 주문 문서를 찾을 수 없어 확인하기 위해 사이트에 몇 가지 다른 사용자 정의 페이지를 탐색 포함의 범위는 _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. 그것을 발견하면, 그것은 포함됩니다. 합니다 ($_GET['url'] 검사가 main.php에서 이루어집니다 후 ) main.php로 돌아 간다
• , 그것은이 ErrorControlChainit 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.phpErrorPage_controller보다는 그것을 해킹하는 것이 가장 좋습니다.

<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의 사용을 변경하거나 추가 오류의 힙을 일으킬 것입니다 :

재 기동를 들어 SS의 기본 .htaccess 파일이 수행 비애.

코어/프레임 워크를 해킹하지 않으려면 .htaccess 파일을 mysite의 main.php 사본을 대상으로 변경하십시오 (적절한 포함 변경 사항 포함).