--=REKLAMA=--
--=REKLAMA=--
Poradnik charakteryzuje szczegółowo wymagania, jakie winien spełniać serwer internetowy, na którym zamierzamy instalować Joomla.
Serwer Apache konfigurowany jest tak, aby wydajnie, skutecznie i bezpiecznie obsługiwać witryny wszystkich korzystających z serwera. Globalne ustawienia z natury rzeczy są dobierane przez administratorów tak, aby dobrze służyły wszystkim klientom. Dla korzystania z Joomla! znaczenie ma przede wszystkim konfiguracja PHP, której trzeba się przyjrzeć bardzo dokładnie przed podjęciem decyzji o korzystaniu z konkretnej oferty. Z kwestii dotyczących ściśle konfiguracji Apache, warto zwrócić uwagę na cztery kwestie:
W sytuacjach, gdy serwer Apache nie zapewnia optymalnych dla Joomla! warunków, pożądana jest możliwość modyfikacji niektórych ustawień za pomocą plików .htaccess. M.in. można oczekiwać od usługodawcy, aby serwer umożliwiał:
Na dokonywanie lokalnych zmian konfiguracji Apache, zwanych też zmianami na poziomie katalogu, pozwala specjalny plik konfiguracyjny – .htaccess. Ale nie na wszystkich serwerach można z niego skorzystać. Nie tylko dlatego, że administratorzy wyłączają możliwość korzystania z .htaccess ze znanych sobie powodów, ale czasem ze względu na specyficzną konfigurację serwera. Gdy PHP uruchomiony jest w trybie FastCGI, zmiana niektórych ustawień możliwa jest za pomocą lokalnych plików php.ini.
Zawierając umowę z dostawcą usług, warto rozpoznać dokładnie możliwości korygowania konfiguracji Apache.
Dbałości o bezpieczeństwo nigdy dość, a dobrej ochrony tym bardziej. Decydując się na wybór dostawcy serwera czy miejsca na serwerze, warto sprawdzić, czy w swej polityce ochronnej wykorzystuje to narzędzie. ModSecurity jest przeznaczoną dla serwera Apache zaporą sieciową, podnoszącą w znacznym stopniu bezpieczeństwo serwera. Jego zasadniczym walorem jest ochrona zasobów na poziomie aplikacji, a więc inaczej niż w przypadku większości typowych zapór sieciowych, które chronią zasoby na poziomie protokołu TCP/IP.
Moduł przeszukuje zapytania przychodzące i wychodzące zgodnie z regułami filtrowania i wykonuje ustalone w nich działania. Solidni i fachowi dostawcy usług internetowych dopasowują podstawową konfigurację ModSecurity do potrzeb każdego klienta, a dokładniej, do używanego przez klientów oprogramowania, np. systemów CMS.
Joomla! w swej standardowej wersji zwykle pracuje poprawnie z typowymi ustawieniami ModSecurity, ale generalnie jest to zależne od indywidualnych ustawień dokonanych przez dostawcę usług internetowych. Jeżeli napotkasz konflikt pomiędzy Joomla! i ModSecurity, to najczęściej będzie on spowodowany przez komponent autorstwa osób trzecich, a czasami nawet wysłaniem formularza, który generuje problem. Zgłoś w takim przypadku sprawę administratorowi serwera – użytkownicy serwerów nie mają innej możliwości wpływu na konfigurację ModSecurity, zarządzanego z poziomu serwera.
Konfigurując ModSecurity, należy zdawać sobie sprawę, że nie tylko sam Joomla! może wymagać unikalnych ustawień, ale także przetwarzanie zainstalowanych rozszerzeń oraz – co zrozumiale – innych aplikacji.
Konfiguracja ModSecurity jest zbyt obszerna i skomplikowana, by ją tu opisywać. Więcej dowiesz się w tych zasobach [1]
Mod_rewrite jest nieco tajemniczym i skomplikowanym – „jak magia woodoo” – rozszerzeniem Apache, umożliwiającym manipulowanie adresami URL, pozwalającym między innymi na zmianę postaci skomplikowanych adresów generowanych przez Joomla! na znacznie prostsze, czytelniejsze i łatwiejsze do zapamiętania. Wykorzystywany jest także do ochrony witryny przed atakami pospolitych exploitów. Do działania Joomla! nie jest wprawdzie niezbędny, ale wielce użyteczny. A ponieważ nie należy do standardowo instalowanych na serwerach, analizując ofertę, warto zwrócić na ten aspekt konfiguracji Apache uwagę, a z dwóch podobnych ofert wybrać tę z mod_rewrite.
Historycznie rzecz biorąc, środowisko PHP można było uruchomić w jednym z dwóch trybów:
Począwszy od PHP5 firmy hostingowe mogą skonfigurować na jednym serwerze obie wersje oraz zastosować rozwiązania hybrydowe, łączące zalety oraz minimalizujące ograniczenia tych wariantów.
Uruchamianie PHP jako modułu Apache oznacza, że jest on dołączony do procesu Apache, jest jego częścią. Moduł ładowany jest tylko jeden raz, a dla każdego żądania tworzony jest nowy wątek. W rezultacie serwer obsługuje żądania szybciej, jest wydajniejszy, ale zagrożona jest jego stabilność – błędy w skryptach czy wycieki pamięci mogą następować zaburzenia w pracy całego systemu. Skonsolidowanie PHP na serwerach współdzielonych niesie za sobą także inne zagrożenia – PHP uruchomiony jako moduł Apache działa z uprawnieniami użytkownika uniwersalnego, a nie z prawami użytkownika realnego – właściciela konta.
PHP w trybie CGI działa jako osobna aplikacja, a zatem każde żądanie rozpoczyna nowy proces. W rezultacie następuje spowolnienie serwera, ale – tracąc na wydajności – zyskujemy na stabilności i bezpieczeństwie serwera. Błędy w skryptach spowodują co najwyżej zawieszenie procesu, a nie całego serwera, a ponadto każdy proces – po odpowiedniej konfiguracji – może być uruchamiany z prawami realnego użytkownika konta (zwykle tego samego, co FTP).
Na serwerach współdzielonych, a więc wykorzystywanych przez wielu użytkowników, stosowane są rozwiązania hybrydowe, łączące zalety obu trybów. Na serwerze instalowany jest FastCGI, który przejmuje na siebie obsługę wywołań CGI. O ile w przypadku CGI dla każdego żądania użytkownika tworzony jest oddzielny proces, to FastCGI potrafi obsłużyć w ramach pojedynczego procesu większą ilość żądań. W rezultacie mamy sytuację podobną, jak w przypadku PHP uruchomionego jako moduł, ale z zaletami trybu CGI. Efektem jest nie tylko większa wydajność serwera, ale i zwiększone bezpieczeństwo. FastCGI może pracować na prawach użytkownika i grupy innej, niż Apache. Zastosowanie oprogramowania typu suExec, php_suExec czy też PHPsuExec pozwala rozwiązywać problemy z prawami własności, chociaż – jak dowodzą liczne zgłoszenia na forum użytkowników, nie jest to rozwiązanie tak bezproblemowe, jak można by oczekiwać czy nawet spodziewać się na podstawie – chyba jednak zbyt „literackich” opisów.
Tryb FastCGI niesie za sobą także inne problemy, między innymi ogranicza możliwości korzystania z plików .htaccess i php.ini, pozwalających na zmianę ustawień skonfigurowanych dla całego serwera. Rozwiązanie tego problemu leży oczywiście w gestii usługodawcy, który powinien udostępnić jakąś metodę korygowania globalnych ustawień PHP czy przełączenia z PHP5 na PHP4 w razie, gdyby starsze, niedostosowane do PHP5 skrypty wymagały zastosowania tego wydania interpretera.
Przodek Joomla! – Mambo – został napisany w PHP4, ale już pierwsze wydanie Joomla! we wrześniu 2005 roku zostało w pełni przystosowane do obsługi przez PHP5, które miało swoją inaugurację zaledwie 14 miesięcy wcześniej, w lipcu 2004 roku. Z informacji o minimalnych wymaganiach Joomla! wiemy wszakże, że do uruchomienia wersji 1.0 wystarczy PHP 4.2.x, a do uruchomienia Joomla 1.5 wystarczy PHP w wersji 4.3.10.
Czy zatem tytułowy dylemat – PHP4 czy PHP5 – ma jakieś praktyczne znaczenie, skoro można uruchamiać Joomla! w każdej z tych linii rozwojowych.
Wiadomo, że kolejne wydania każdego programu niosą ze sobą udoskonalenia i poprawki, w tym podwyższające bezpieczeństwo. PHP nie jest pod tym względem żadnym wyjątkim. Toteż – jak w każdym innym, tak i w przypadku PHP praktyką najrozsądniejszą i zalecaną jest korzystanie z najnowszej stabilnej wersji. Zgodnie z tą tendencją niektóre z firm hostingowych, na szczęście, nieliczne, w ogóle zrezygnowały z obsługi PHP4, a wiele unowocześniło oprogramowanie, zapewniając standardowo obsługę PHP5 i możliwość przełączenia w razie potrzeby na PHP4.
W przypadku Joomla! przełączenie na PHP4 może być konieczne tylko i wyłącznie wówczas, gdy korzystamy ze starych rozszerzeń, napisanych w najlepszych, ale minionych już czasach rozwoju tego wypuszczenia PHP. Bardzo często, a można by zaryzykować stwierdzenie, że niemal zawsze, są to rozszerzenia podatne na ataki cyberprzestępców. Korzystanie z takich rozszerzeń nie jest więc zbyt rozsądne. Na wszelki jednak wypadek lepiej dysponować serwerem, na którym przełączenie PHP jest możliwe, niż serwerem, który takiej możliwości nie udostępnia, uniemożliwiając na przykład migrację witryn założonych na Joomla 1.0 do Joomla 1.5.
Podkreślmy wszakże mocno raz jeszcze, iż wbrew spotykanym jeszcze opiniom, PHP w wersji 5.x.x jest dobrym rozwiązaniem dla Joomla!
Odpowiednie dla Joomla! ustawienia PHP można podzielić na trzy grupy: podstawowe, zalecane oraz pożądane, ale niekonieczne. Z informacjami o ustawieniach serwera, na którym będziesz instalować Joomla!, spotkasz się już na pierwszym ekranie instalatora. Objaśnijmy dokładnie, co oznaczają i jakie mogą powodować skutki.
Trzy wymagania są dla pełnej obsługi Joomla! niezbędne:
Bez włączonej obsługi XML Joomla! nie będzie działać. Skrypty XML zawierają m.in. instrukcje konfigurujące pozycje menu, komponenty, moduły, boty i szablony. XML, ZLib oraz GD lub GD2 są standardowo obsługiwane przez serwery internetowe.
Bez obsługi XML Joomla nie zadziała w ogóle. Skrypty XML zawierają m.in. instrukcje konfigurujące pozycje menu, komponenty, moduły, dodatki i szablony. Bez ZLib i biblioteki graficznej od wielkiej biedy obyć się można, ale ich brak w gruncie rzeczy powinien być czynnikiem dyskwalifikującym serwer. Biblioteka Zlib umożliwia kompresję i dekompresję spakowanych plików. Można się wprawdzie bez tej funkcji obyć, ale jej brak stanowi poważne utrudnienie. Wszystkie trzeba instalować z rozpakowanych i przesłanych na serwer pakietów źródłowych. Niemożliwe jest również korzystanie ze wszystkich funkcji komponentów obsługujących plikownie czy galerie grafik.
GD jest biblioteką graficzną, umożliwiającą manipulację obrazami - m.in. dynamiczne tworzenie miniatur. Biblioteka jest dostępna na warunkach GNU GPL pod adresem www.libgd.org. Bez biblioteki graficznej - GD lub GD2 – również można posługiwać się Joomla. Ale jej brak w gruncie rzeczy powinien być czynnikiem dyskwalifikującym serwer, bo nie sposób wydawać dynamicznej witryny internetowej bez możliwości wykonywania podstawowych operacji na obrazkach.
Ustawienia zalecane, zgodnie ze znaczeniem słowa zalecane, gwarantują najlepsze według projektantów środowisko dla działania Joomla!, ale to nie oznacza, iż inne ustawienia uniemożliwią korzystanie z Joomla! Nie oznacza to również, iż można zalecane ustawienia zlekceważyć! Każde odstępstwo od zalecanych ustawień może być źródłem problemów i ograniczeń w działaniu Joomla! czy też zagrożeń dla bezpieczeństwa – zarówno samej witryny, jak i serwera. Dlatego, decydując się na wybór serwera i usługodawcy, powinniśmy w pierwszej kolejności odrzucić bez skrupułów oferty, z których wynika, że zalecane ustawienia ani nie są spełnione, ani nie można ich zmodyfikować. Należy też się wystrzegać usługodawców, którzy z jakichś względów preferują ustawienia zagrażające bezpieczeństwu. Czym innym jest bowiem zgoda na zastosowanie lokalnie niezbyt bezpiecznego rozwiązania od zastosowania niebezpiecznych ustawień w konfiguracji globalnej.
Joomla! działa zarówno z PHP w bezpiecznym trybie [safe_mode=OFF], jak i przy wyłączonym trybie bezpiecznym. Na co dzień, gdy już Joomla! zostanie dostosowany do naszych potrzeb, gdy zainstalujemy wszystkie potrzebne rozszerzenia, bezpieczny tryb zapewne nie da o sobie znać. Ale każda próba instalacji czegokolwiek zakończy się niepowodzeniem! Bezpieczny tryb jest dla administratorów szczególnie uciążliwy w okresie tworzenia zrębów witryny. Gdy PHP działa w trybie bezpiecznym, niemożliwe jest instalowanie rozszerzeń – komponentów, modułów, dodatków, szablonów, języków. Dokładniej rzecz biorąc, niemożliwe jest utworzenie katalogów niezbędnych do zainstalowania nowego składnika. Dzieje się tak, ponieważ w bezpiecznym trybie rozmyślnie są wyłączone funkcje pozwalające na łatwe wczytywanie plików przez przeglądarkę internetową. Z instalacją rozszerzeń można sobie, oczywiście poradzić, korzystając z niewygodnej procedury „instalacji ręcznej”, bo na chwilowe nawet wyłączenie tego trybu przez administratorów raczej nie ma co liczyć (choć spróbować można!).
Na serwerach z włączonym trybem bezpiecznym najlepiej Joomla! nie instalować! Dlaczego?
Włączenie safe_mode daje fałszywe poczucie bezpieczeństwa. Trybu bezpiecznego używa się na serwerach współdzielonych w sytuacji, gdy administratorzy nie mogą zapewnić lepszych metod ochrony przed zagrożeniami. Stosowanie bezpiecznego trybu jest złym kompromisem w złej sytuacji. Prawie zawsze są lepsze i skuteczniejsze metody ochrony witryn i serwerów. Dlatego z PHP6 tryb bezpieczny zostanie usunięty zupełnie. Oto, co o bezpiecznym trybie napisano w oficjalnej dokumentacji:
Jeśli korzystamy z Joomla 1.0, a serwer działa w bezpiecznym trybie, można w zasobach znaleźć specjalną łatkę eliminującą problemy. Niestety, ostatnia z opublikowanych została opracowana dla Joomla 1.0.12. Dostosowanie jej do Joomla 1.0.15 wymagałoby interwencji programisty.
Na zakończenie warto podkreślić, że w pewnych okolicznościach włączony tryb bezpieczny ma swoje zalety – gdy mamy do czynienia z rozszerzeniami innych zespołów projektowych niż Centrum Projektu Joomla!. Zdarza się, ze takie rozszerzenia wymagają funkcji blokowanych przez bezpieczny tryb. Takie rozszerzenia warto poddać analizie dobrego programisty, by ocenił powody, dla których wymagają one funkcji potencjalnie niebezpiecznych.
Nie tylko bezpieczeństwo Joomla!, ale bezpieczeństwo wszystkich aplikacji PHP wymaga wyłączenia rejestracji zmiennych globalnych (ustawienia: register_globals=0). Oto zwięzła, acz jednoznaczna ocena tej „możliwości”: „Automatyczne rejestrowanie zmiennych globalnych było prawdopodobnie najgłupszą decyzją projektantów PHP”. Rejestrowanie zmiennych globalnych powoduje, że stają się one łatwo dostępne dla wszystkich skryptów PHP, łatwo je nadpisać. Tę sytuację mogą wykorzystać nawet średnio zaawansowani rozbójnicy internetowi, aby np. oszukać procedurę autoryzacji. Projektanci PHP zdali sobie sprawę ze swojego błędu i zrezygnowali z tej – podkreślmy wyraźnie – groźnej właściwości. Niestety, wykorzystywana była w wielu starszych komponentach. Dlatego w Joomla 1.0 stworzono mechanizm emulacji register_globals, dzięki któremu można było korzystać z rozszerzeń starszej daty. W internetowych publikacjach o Joomla 1.0 spotkać można opinię, że emulacja RG jest nieco bezpieczniejsza od ustawienia register_globals=1. Ale, cóż tu w gruncie rzeczy może oznaczać słowo ‘bezpieczniejsze’? Czy otwarta furtka nie będzie nadal otwartą tylko dlatego, że do otwarcia użyjemy innego wytrycha? Wadliwe rozszerzenia trzeba jak najszybciej zastąpić nowocześniejszymi – albo innymi, albo wersjami naprawionymi. Wystarczy sobie uzmysłowić, że pozostawienie włączonej rejestracji zmiennych globalnych było w kilkuletniej przeszłości Joomla! najczęstszą przyczyną włamań! A swoistą przestrogą dla administratorów może być fakt, że nie ustrzegło się tego błędu m.in. Centrum Projektu (sierpień 2008 r.) i Polskie Centrum Joomla! (luty 2009). Obie witryny zostały w różnych momentach skutecznie zaatakowane przez rozszerzenia wymagające rejestrowania zmiennych globalnych!
W Joomla! dostęp do zmiennych EGCPS (Environment, GET, POST, COOKIE i Server) realizowany jest za pomocą składni typu $HTTP_GET_VARS['zmienna'], toteż włączanie register_globals jest zbędne.
Rejestrowanie zmiennych globalnych można wyłączyć na serwerze lokalnie, dla katalogu witryny. Wystarczy w pliku .htaccess wpisać wiersz:
php_flag register_globals 0.
|
Porada Jeżeli administrator serwera współdzielonego, z którego korzystasz, wlączył register_globals na serwerze, masz poważny powód do zmartwienia. Lokalne przełączenie tego ustawienia niewiele zmieni, bowiem inne strony na serwerze będą narażone na ataki, których skutki mogą dosięgnąć i twoich witryn. |
Możliwość poznania przyczyn błędów w działaniu skryptów jest administratorom Joomla! niezbędna. Wyświetlanie komunikatów o błędach zapewnia opcja display_errors=ON. Włączenie tej opcji stwarza jednak zagrożenia! Wszak komunikaty o błędach zawierają m.in. pełne ścieżki do plików, wersje oprogramowania, fragmenty zapytań SQL, które można złośliwie wykorzystać. Problem jest w Joomla! rozwiązany – w konfiguracji globalnej można ograniczyć poziom wyświetlania komunikatów o błędach lub wyłączyć je zupełnie, a włączać jedynie na czas rozwiązywania problemów.
|
|
Porada Temu celowi służy również specjalny tryb diagnostyczny, który można zarządzić w konfiguracji globalnej. Domyślnie jest on wyłączony. Początkującym administratorom zdarza się przypadkowe ustawienie tej opcji na Tak, kończące się zwykle alarmami na forum użytkowników, że na stronie pojawiają się dziwne komunikaty. No cóż, dziwne, że się pojawiają, bo diagnostykę strony można prowadzić w specjalnym trybie administracyjnym, wyłączając widoczność witryny w sieci na czas testów i prac konserwacyjnych. |
Możliwość wczytywania plików binarnych, wysyłanych metodą POST, jest często dla Joomla! nieodzowna. PHP powinno więc działać z włączoną dyrektywą file_uploads. Bez takiego ustawienia nie będzie możliwe instalowanie rozszerzeń ani przesyłanie plików do biblioteki mediów czy innych katalogów.
Trzy ustawienia PHP odpowiadają za cytowanie znaków niebezpiecznych: magic_quotes, magic_quotes_gpc oraz magic_quotes_runtime. Gdy 'magiczne ukośniki' są włączone, wszystkie znaki apostrofu ('), cudzysłowu ("), lewe ukośniki (\) oraz znaki NULL są poprzedzane znakiem lewego ukośnika (\). Takie ustawienie chroni Joomla! przed atakami typu SQL Injection [’wstrzykiwania zapytań SQL’] w przypadkach, gdy programista zapomni gdzieś przefiltrować dane przesyłane przez użytkowników w formularzach.
Włączenie opcji magic_quotes_gpc ustawia stan magic_quotes dla operacji posługujących się zmiennymi z tablic superglobalnych [POST, GET COOKIE]. Jeśli jest włączona, to PHP automatycznie dodaje lewy ukośnik do wszystkich operacji posługujących się zmiennymi GPC, wykonując funkcję addslashes() – poprzedza lewym ukośnikiem wszystkie znaki niebezpieczne.
Dyrektywa magic_quotes_runtime natomiast ma wpływ tylko na niektóre funkcje wykonujące operacje addslashes() i na niektóre ich niewykonujące operacji addslashes(). W efekcie jej włączenia większość funkcji, które zwracają dane z dowolnych zewnętrznych źródeł, włącznie z danymi z baz danych i plików tekstowych, będzie zwracała dane z apostrofami i cudzysłowami poprzedzonymi znakiem lewego ukośnika (\) funkcje wykonujące operację addslashes() to file(), file_get_contents(), fread(), fgets(); a niewykonujące to readfile(), parse_ini_file(), fgetss(), fgetc(), fgetcsv(), fscanf().
Zalecanym ustawieniem magic_quotes_gpc dla Joomla 1.0 jest ON, aby chronić witrynę przed skutkami wykorzystania błędów w źle napisanych skryptach rozszerzeń.
Joomla 1.5 ignoruje to ustawienie i działa poprawnie w każdym przypadku. W przypadku Joomla 
i wyższych wymagane jest ustawienie OFF.
Opcja output_buffering domyślnie jest w ustawieniach PHP, zgodnie z zaleceniami dla Joomla!, wyłączona. Jej włączenie spowoduje, że żadna informacja z serwera nie zostanie wysłana do przeglądarki do momentu zakończenia skryptu. Zapobiega to np. wysyłaniu nagłówka dokumentu wynikowego, zanim zostaną wysłane ciasteczka [cookies]. Joomla! będzie jednak działać poprawnie zarówno przy włączonym, jak i wyłączonym buforowaniu danych wyjściowych.
HTTP, jak zapewne wiesz, jest protokołem bezstanowym. Dopóki mamy do czynienia z anonimowymi użytkownikami witryny, dopóty nie ma znaczenia, jak jest ustawiona zmienna session_auto_start. Ale w przypadku użytkowników zalogowanych, a zwłaszcza administratorów, niezbędny jest mechanizm śledzenia zachowań użytkownika.
Identyfikator sesji może być przechowywany w plikach cookies lub przekazywany przez URL. Ustawienie session_auto_start=0 automatycznie rozpoczyna sesję i dlatego jest pożądane. Alternatywnie może być ustawiona na ON zmienna session.use_cookies setting.
Jeśli ustawione będą session_auto_start=ON albo jeśli zmienna session.use_cookies setting=OFF, nie będzie możliwe zalogowanie się do witryny ani do panelu administracyjnego. Należy je skorygować. W drugim przypadku konieczne jest odpowiednie skonfigurowanie przeglądarki użytkownika, która musi dopuszczać możliwość zapisywania ciasteczek.
Ustawienie allow_url_fopen włącza możliwość wykorzystywania funkcji fopen(), include() oraz require() do obsługi plików na dysku serwera za pomocą protokołów HTTP i FTP znajdujących się na zdalnych serwerach tylko przez podanie adresu URL. Nieco inaczej mówiąc, jeśli w pliku konfiguracyjnym php.ini jest włączona opcja allow_url_fopen, to na serwerze lokalnym można umieścić pliki z serwera zdalnego, podając adres URL, zamiast lokalnej ścieżki, używając np. takiego polecenia:
include 'http://www.twoja_witryna.com/media/plik.php'
Ustawienie allow_url_fopen=ON jest uznawane za „przyjazne, bowiem umożliwia m.in. automatyczną aktualizację oprogramowania, a więc np. rozszerzeń posiadających taką opcję. Ale bez takiego ułatwienia bez problemu można się obejść zważywszy, że włączenie tej funkcji może prowadzić do wielu problemów: włamań do serwisu, blokady serwera WWW czy znacznego spowolnienia odczytywania strony.
Ze względów bezpieczeństwa wyłączenie tej funkcji jest możliwe tylko w php.ini.
allow_url_fopen = 0
Dwa ustawienia decydują o dopuszczalnych rozmiarach plików przesyłanych na serwer:
Odpowiednie ustawienie zależy od potrzeb witryny. Standardowo administratorzy zezwalają na wczytywanie plików o rozmiarach do 8 MB. Jeśli nasze potrzeby są większe, trzeba poprosić o podwyższenie tej wartości. Wartość dla post_max_size powinna być większa niż dla upload_max_filesize, np. o 1, a wartość memory_limit powinna być jeszcze większa.
Maksymalny czas wykonywania skryptów ustawiany jest standardowo max_execution_time=30. Jeśli po upływie tego czasu skrypt nie zostanie wykonany, jego działanie jest przerywane. Owe 30 sekund jest ustawieniem wystarczającym, chroni przed blokowaniem serwera przez źle napisane skrypty. Jeśli ustawienie to staje się powodem błędu, należy odszukać wadliwy skrypt i albo go poprawić, albo zrezygnować z niego, zastępując innym rozwiązaniem. Na testowych serwerach lokalnych (np. serwerze XAMPP) takie domyślne ustawienie może być niewygodne. Jeśli otrzymujemy komunikat, że upłynął czas na wykonanie skryptu (timeout off) lub przeglądarka sygnalizuje, że skrypt jest wciąż wykonywany, choć upłynęło już sporo czasu, można zwiększyć tę wartość np. do 60 czy nawet do 180 (sekund)
Maksymalny czas oczekiwania na przesłanie strumienia danych ze źródła zależy od ustawienia default_socket_timeout. Najczęściej spotykanym jest ustawienie default_socket_timeout=0. Jeśli ustawienie to stwarza problemy, można zwrócić się do administratora z prośbą o modyfikację na default_socket_timeout=30.
Ustawienie short_open_tag decyduje o rozróżnianiu w skryptach skróconej formy znaczników otwierających – <? zamiast – <?php. Ponieważ Joomla! używa PHP w połączeniu z XML, opcja ta winna być wyłączona [short_open_tag=OFF]. Zdarza się wszakże, że na wielu serwerach jest włączona. W efekcie mogą pojawiać się różnego typu błędy, w przypadkach, gdy PHP napotka skrócone znaczniki otwierające. Wykonywanie skryptu jest zatrzymywane, a niekiedy wyświetlany jest również kod skryptu. Jeśli prośba do administratora o zmianę tego ustawienia nie przyniesie rezultatu, nie ma co wpadać w panikę. Wystarczy przejrzeć skrypty rozszerzenia, które sprawia kłopoty, wyszukać w nich sekwencje „<?” i zastąpić je tekstem „<?php” (oczywiście, wyszukiwać bez cudzysłowów).
Istnieje pewien zestaw funkcji, których Joomla nie używa albo które nie są dla korzystania z Joomla konieczne, a niosą ze sobą różne zagrożenia. Plik php.ini umożliwia zablokowanie możliwości uruchamiania niebezpiecznych funkcji PHP. Oto typowy zestaw ustawień dla witryny opartej na Joomla!:
disable_functions = show_source,system,shell_exec,passthru,exec,phpinfo,popen,proc_open
Umieszczona tutaj funkcja php_info wykorzystywana jest wprawdzie – dla wygody administratorów – na zapleczu administracyjnym Joomla!, ale potrzebna jest w wyjątkowych okolicznościach. Na serwerze zarządzanym samodzielnie można ją również spokojnie wyłączyć.
W przypadku gdy korzystamy z serwera współdzielonego warto przyjrzeć się bliżej umieszczonemu na karcie Ustawienia PHP wykazowi funkcji wyłączonych i być może interweniować u administratora w sprawie wyłączenia tych, które nie są nam potrzebne.
W pliku php.ini możliwe jest ustawienie opcji open_basedir w celu ograniczenia dostępu do określonych katalogów z poziomu skryptów PHP. Gdy ta opcja jest ustawiona, to PHP oganicza funkcje wejścia/wyjścia i funkcje systemu plików tak, że mogą one operować jedynie wewnątrz wskazanego katalogu lub w jego podkatalogach. Nazwa katalogu podawana jako argument w funkcji open_basedir traktowana jest jako prefiks, a nie dokładna nazwa katalogu. Oto przykładowa konfiguracja:
open_basedir = /var/www/html/konto/public_html/joom
Takie ustawienie pozwala na dostęp do katalogów /konto/public_html/joom oraz /konto/public_html/jooml czy /konto/public_html/joomla o ile takie istnieją. Aby ograniczyć dostęp do jednego katalogu, jego nazwę należy zakończyć ukośnikiem, np.
open_basedir = /var/www/html/konto/public_html/joomla/
Użycie kończącego ukośnika w celu ograniczenia dostępu do jednego katalogu, może w niektórych konfiguracjach (PHP od wersji 4.4.8) spowodować przy zapisywaniu globalnej konfiguracji wygenerowanie następującego ostrzeżenia Joomla! JFolder::create: Infinite loop detected. Ponadto, jeżeli open_basedir jest włączona, konieczne może być ustawienie dyrektywy konfiguracji PHP upload_tmp_dir, na ścieżkę, która wchodzi w zakres open_basedir, lub alternatywnie dodać ścieżkę upload_tmp_dir do open_basedir używając odpowiedniego seperatora ścieżki dla systemu hosta.
open_basedir = /var/www/html/konto/public_html:/tmp
Opcja open_basedir może być konfigurowana nie tylko w php.ini, ale także w pliku konfiguracyjnym Apache, używając opcji php_admin_value, w sekcji definiującej host wirtualny, np.:
<VirtualHost www.twoja_domena.com> ServerName www.twoja_domena.com DocumentRoot /var/www/html/konto/twoja_domena php_admin_value open_basedir /var/www/html/konto/twoja_domena </VirtualHost>
Nie można jej konfigurować w .htaccess.
Przypisy