czy twórca jakiejś strony może zablokować dostęp do danej strony jednemu urządzeniu albo całemu adresowi ip?? W jaki sposób ktoś mógłby mi zablokować możliwość wyświetlania witryny? To w ogóle możliwe?
@only_spam: twórcę .htaccess powinni wypatroszyć i pozostawić do zaschnięcia na słońcu
@MoonAteTheDark: da się, na kilku warstwach. Serwer www może zwyczajnie odrzucać połączenia z twojego IP
@MoonAteTheDark: może, ale zwykle nie ma powodu by to robić. Da się to zrobić na wielu poziomach - od serwera www, serwer fizyczny na którym to stoi, przez Twojego dostawcę internetu, dostawcę DNS (zazwyczaj ten sam co poprzedni), po Twoją sieć wewnętrzną, domowy router, czy sam komputer.
@zskk: E tam, nie ma tragedii, w sumie się przyzwyczaiłem :D
@MoonAteTheDark: http://www.cms.rk.edu.pl/w/p/zabezpieczanie_htaccess/ - przykładowo za pomocą htaccess
@only_spam: konfiguracja bezposrednio w /etc/httpd/ albo /etc/nginx/ :P obsluga .htaccess powinna byc wylaczona na poziomie serwera
@only_spam: @Writer: dobra, musiałem zjeść sniadanie :P
Więc tak. Idea .htaccess odbiera administratorom możliwość kontroli nad konfiguracją i zachowaniem poszczególnych location. Po drugie .htaccess wymusza kaskadowe sprawdzanie reguł i ich odpowiednią konkatenację. Oznacza to, że dla adresu example.com/some/long/path/to/very/deep/subdirectory/where/file/possibly/exists/or.not zamiast pojedynczego odczytu z dysku będzie sprawdzenie dla każdego folderu nadrzędnego istnienie pliku .htaccess (czyli co najmniej 12 odczytów z dysku dla samych konfiguracji), złożenie tych konfiguracji w całość, interpretacja jej (nie jest kompilowana przy starcie - jest dynamiczna) i późniejsze odczytanie pliku (bądź wykonanie rewrita do nowej lokacji i... cykl zaczyna się od nowa [no chyba ze jest last]). Powoduje to gigantyczny narzut przy wykonaniu prostego GETa. Ogólnie użytkownicy nie powinni mieć uprawnień do mieszania w ten sposób na serwerach. Wszelkie redirecty powinni juz obsługiwać w kodzie swoich programów. Tak samo listingi folderów czy inne cuda. Administrator nie powinien poświęcać stabilności, wydajności i bezpieczeństwa serwera (vide exploitacje apacza poprzez cudaczne redirecty) nad wygodę użytkowników - szczególnie, że oni mogą to zrobić wszystko we własnym zakresie w swoim kodzie.
@zskk: No ok, robisz narzut na apache'a i to Ci nie odpowiada, a co z narzutem na PHP robiąc to w skrypcie? Przecież to jest dużo większy narzut robić taki router. No i kwestia przeniesienia do skryptów zmniejsza rażąco bezpieczeństwo. Bo wystarczy wstrzyknąć, w źle napisany skrypt, odpowiednie parametry i dopiero wtedy się zaczyna jazda :P
@only_spam: Z tym, że w przypadku php mozna zrobic jedną definicje redirecta i będzie jeden odczyt pliku (względnie plus importy) - zasobów CPU jest z reguły kilka rzędów wielkości więcej niż IO dyskowego. PHP powinien też działać w scope tylko danego użytkownika, więc jeśli sobie coś popsuje to już u siebie - can't care a less :P Co więcej - z apachem był jeszcze problem, że każde połączenie powodowało stworzenie osobnego procesu (20~40mb w zależności od ilości bibliotek i dodatków) więc im dłużej trwało połączenie podczas ktorego bylo sprawdzane drzewo folderow, tym gorzej. Nginx szczęśliwie nie ma tego problemu, a procesy php-fpm zajmują wymiernie mniej RAMu (4mb). Do tego php-fpm umie pre-warmować procesy więc działa to znacznie sprawniej.
@zskk: Czyli chcesz mi powiedzieć że odczytanie pliku htaccess ma większy narzut I/O od zrobienia PHPowego routing /bardzo/ladnych/linkow? :P Nie chcę wyjść na obrońcę .htaccess bo sam wolę użyć nginx + php-fpm zamiast apache, ale tylko mówię że htaccess, w przypadku generowania /takich/linków, jest dużo łatwiejsze i mniej zasobożerne niż podciąganie tego pod PHP.
@only_spam: tylko już mówiłem - koszt CPU przy obróbce pliku.php który i tak będzie zaczytany żeby wykonać resztę roboty vs odczytanie htaccessów a pozniej pliku php, to odpowiedź jest oczywista. Ze strony admina wystarczy podstawowe obcinanie .php względnie dorzucenie jednego globalnego rewrite index.php?$request_uri daje własciwie wszystko użytkownikom.