Większość ofert hostingowych w Polsce od zawsze udostępnia nam jeden katalog, ew. możliwość wskazania dla danej domeny katalogu gdzie przechowujemy nasz projekt.
Dzięki temu wystarczy do niego wgrać aplikację i wszystko działa.
Kiedyś nie stanowiło to problemu, gdy cała aplikacja była w jednym worku, a za pomocą odpowiednich sztuczek nie pozwalało się na bezpośredni dostęp do plików źródłowych PHP lub konfiguracyjnych.
Obecnie, np. z punktu widzenia osoby tworzącej z wykorzystaniem Zend Framework stanowi to problem, ponieważ domyślny układ projektu wygląda tak:
|
1 2 3 4 5 6 7 |
application/ controllers/ views/ scripts/ library/ public/ tests/ |
Ze względów m.in. bezpieczeństwa w ZF jest wydzielony jeden katalog publiczny (public), który jest domyślnym katalogiem dostępnym z Sieci. Gdy taką aplikację umieścimy np. na hostingu w home.pl aplikacja nam się nie uruchomi, a każda osoba z Internetu będzie miała dostęp do wszystkich plików (pliki PHP nie stanowią problemu, ale już pliki INI, SQL tak). Wiele osób przegrywa plik index.php do katalogu nadrzędnego odpowiednio go modyfikując – to błąd. Owszem, aplikacja zadziała, ale nie poprawi to względów bezpieczeństwa.
Problem można bardzo łatwo rozwiązać jeśli nasz usługodawca daje możliwość umieszczania plików .htaccess:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
RewriteEngine On RewriteRule ^\.htaccess$ - [F] RewriteCond %{REQUEST_URI} ="" RewriteRule ^.*$ /public/index.php [NC,L] RewriteCond %{REQUEST_URI} !^/public/.*$ RewriteRule ^(.*)$ /public/$1 RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^.*$ - [NC,L] RewriteRule ^public/.*$ /public/index.php [NC,L] |
|
1 2 |
Wystarczy go umieścić w katalogu głównym, a on załatwi już odpowiednie przekierowania poszczególnych wywołań. Oczywiście jeśli mamy możliwość konfiguracji <em>vhost-ów</em> lub ustawienia katalogu aplikacji w inny sposób powinniśmy z niego skorzystać, zamiast cudować z <em>htaccess</em>. |