이 가짜 docroot가 너무 흐릿한가요?

Question

필자는 응용 프로그램의 PHP 파일을 docroot 위에 저장하는 것을 좋아합니다.

그러나 공유 호스트는 많은 허튼 소리도 저장합니다. 그것은 엉망이 보인다.

내가이 일에 대해 궁금

... .htaccess 파일이 포함되어

users/alex/public_html/ 
- .htaccess 
- application/ 
- system/ 

users/alex/public_html/www/ 
- index.php 
- assets/css 
- assets/js 

...

RewriteEngine On 
RewriteRule .* www/$0 

그래서, 내 웹 루트에 대한 모든 요청은 자동으로 www/에 다시 쓰여집니다 폴더.

너무 얇은가요?

Answer 1

실제적인 위험이 있다고 생각하지 않습니다. 본질적으로, 웹 서버에 대한 신뢰가 문서 루트에 대한 웹 액세스를 제한하는 것과 동일한 역할을 수행하도록하는 것입니다. 고려해야 할 몇 가지 포인트가 있습니다.

먼저, .htaccess 파일의 mod_rewrite 규칙 집합은 특이성 측면에서 선택적으로 평가됩니다. URL이 /category/path/이고 다음 디렉토리 구조 (모든 .htaccess 파일에 mod_rewrite 룰 세트가있는 것으로 가정) 경로/의 .htaccess 파일 만 평가됩니다.

 
public_html/ 
|- .htaccess 
|- category/ 
    |- .htaccess 
    |- path/ 
     |- .htaccess 

그렇다면 왜 이것이 문제가됩니까? 문서 루트 위에있는 응용 프로그램 폴더 중 하나에 .htaccess 파일이 있고 적어도 RewriteEngine On이라고 가정하면 루트 .htaccess 파일의 RewriteRule이 적용되지 않습니다. 이것은 쉽게 피할 수 있습니다.

둘째, (정적 자원 포함)모든 요청은 htaccess로 파일을 해석의 오버 헤드가 발생하지 않을뿐만 아니라, 적어도 하나의 내부 리디렉션을 수행 할 것이다. 이 오버 헤드를 매우 중요하게 생각하지 않지만 사이트 트래픽이 많은 경우 약간의 영향이있을 수 있습니다. 그 시점에서 어쨌든 더 유연한 호스팅을 사용하면이 프로세스가 필요하지 않게 될 것입니다.

이러한 문제를 염두에두고 나는 효과적인 문서 루트를 바꾸기 위해 다시 작성하는 것이 더 나쁘지 않다고 생각합니다. 어떻게 든 .htaccess 파일을 엉망으로 만들었더라도, mod_rewrite는 설정이 무효 인 경우에 내부 서버 오류를 던질 것이기 때문에 당신이 우려하는 유일한 이유는 기대했던 것 이외의 것을 한 규칙 일 것입니다. 그와 관련하여

, 나는 다음과 같이 변경하기 권하고 싶습니다 :

/.htaccess

RewriteEngine On 

RewriteRule .* /www/$0 

/www/.htaccess을

RewriteEngine On 

# Check if the original request was to /www/something and redirect 
RewriteCond %{THE_REQUEST} ^[A-Z]+\s/www/ 
RewriteRule .* /$0 [R=301,L] 

# The rest of your rules...