Proszę o pomoc przy mojej stronie.

[TQM]

Wygoda ogromna i na prawde nie ma czego popsuc. Jesli mowa o CMSie gdzie Ty publikujesz content to na prawde nic tego nie pobije.
Zgodnosc jest pelna z kazda przegladarka i kazdym systemem operacyjnym jaki tylko gada TCP i ma dowolna przegladarke WWW. Inna kwestia jest to, czy szablon ktory przygotujesz i ktory CMS wypelni danymi (i zapisze plik wynikowy) bedzie przystosowany do kazdej przegladarki... ale to zalezy od usera (ownera).
SEO - linki sa przyjazne i sa odwzorowane na pelne sciezki w systemie plikow. Zawsze mozna dodac mod_rewrite - jedno drugiemu nie przeszkadza (np wyciac boty, hotlinkowanie, itp).
Wydajnosc taka jakbys pobral index.html ktory mowi "It works!" i prawde mowiac to jest to samo. Publikujesz nowy tekst, jest on zapisywany w bazie, opala sie skrypt ktory leci przez baze i generujesz wszystkie katalogi jakie potrzeba, wszystkie pliki HTML, itd. Grafika jest umieszczana we wlasciwych miejscach, CSS, JS jesl jest tez... dalej strone mozesz spakowac+ftp/rsync/cokolwiek i miec sam czysty content bez zadnego oskryptowania ktore mozna atakowac.

... i to nie to samo co nawet najlepiej napisany kod PHP, bo ten trzeba uruchomic, zjada zasoby i wymaga tysiecy linii kodu zrodlowego ktory musi zostac skompilowany, zaladowany do pamieci i dzialac jako interpreter, pozniej na zawolanie wczytac plik, przeanalizowac jego zawartosc, skompilowac zawarty tam kod i wykonac - to zajmuje czas, zajmuje pamiec, wydluza czas odpowiedzi... dodaj do tego jeszcze baze danych i zbiera sie niezla miarka.

Miejsce na nowe technologie jest i to nie malo... wiekszosc osob uwaza to co pisze za przezytek - wiem... i w ogole mi to nie przeszkadza. Po prostu to co pisze to wynik miesiecy solidnych testow na roznych platformach w roznych konfiguracjach. Ty wiesz gdzie ja pracuje i co robie, wiec wiesz po co mi sa potrzebne tak bezpieczne i wydajne rozwiazania.


Przyklad sprzed miesiaca:
Feed danych (XML) dla jednej ze stron - widget we flashu, pobiera dane co 60 sekund... srednio okolo 20-30 trafien na sekunde w pierwszym tygodniu jak strona poszla live. XML generowany przez skrypt w PHP ktory robil 1 proste zapytanie do bazy - maszyna zatkana momentalnie, strony sie nie laduja, apache nie reaguje, PHP uzywa 90% CPU, kolejne 10% to baza, swap sie konczy bo RAMu braklo chwile temu (4GB). System lezy, OOM Killer pozdrawia

Modyfikacja 1:
dodanie xcache, wydajnosc w gore o okolo 20% ale to nadal za malo - mamy 26 do 40 zapytan na sekunde, nadal PHP zjada >3/4 RAMu i nie wyrabia z obsluga kolejnych trafien

Modyfikacja 2:
koder ktory to napisal i nie pomyslal o wydajnosci i pojemnosci serwera (a doslownie mowiac nie dotarlo do niego ze serwer to nie studnia bez dna) dostaje opierdol od szefostwa bo polozyl zafundowal nam DoS'a - stalismy sie ofiarami wlasnego sukcesu - placimy podatek od glupoty... koles modyfikuje skrypt tak, ze ten nie pyta bazy o dane czesciej niz raz na minute, ostatni timestamp zapisuje w pliku razem z wynikiem zapytania do bazy. PHP zjamuje nadal 3/4 RAMu, obciazenie bazy staje sie malo widoczne ale CPU caly czas >90% i kazdy podmuch ruchu powoduje zatkanie systemu...

Modyfikacja 3:
odbieram kolesiowi dostep do serwera i wysylam na kurs programowania w PHP, odpalam jego skrypt co minute z cron'a i zapisuje wynik do pliku tekstowego, odpalam mod_rewrite i przekierowuje URL gdzie flash szuka XMLa na plik tekstowy... CPU wraca do 5-7%, ilosc obsluzonych polaczen przekracza 120/sek w ciagu pierwszych minut po wprowadzeniu zmian, zuzycie RAM wraca do normy, wentylatory w serwerach zmniejszaja obroty...

Serwowanie statycznych plikow zalatwia problem... ostatnia modyfikacja to wylaczenie mod_rewrite (bo analiza regul tez zajmuje czas i I/O dyskow w wiekszosci przypadkow) i opisanie calosci przy uzyciu mod_alias w konfiguracji hosta. I jeszcze jedna uwaga - napisalem "wentylatory w serwerach" - powyzej podalem srednie dane z clustra skladajacego sie z 4 calkiem fajnych maszyn.

Czy teraz to co napisalem wczesniej o generowaniu statycznego pliku i serwowaniu go kiedy jest taka potrzeba wyglada nieco inaczej? Do tego jeszcze dodaj fakt ze wiele prywatnych stron jest hostowana na wspoldzielonych serwerach gdzie iles osob uzywa PHP i gownianego kodu ktory ma dzialac ale nie pomyslano o wydajnosci. Jesli masz strone na takim wlasnie serwerze, wtedy roznice bedzie kolosalna!

UPDATE:
Ostatni argument w dyskusji jest taki, ze systemy CMS nie potrzebuja automatyki/skryptow za kazdym razem kiedy trzeba wyswietlic dane. Jesli masz na stronie forum to ono oczywiscie potrzebuje kodu aby dzialac ale wyprzedzajac pytanie... forum to z definicji nie jest CMS.

[eMCe]

Hymm...
Hymm...
Hymm... Hymm... Hymm...
Praktycznie rzecz biorąc jeśli dobrze rozumiem slowko CMS oznacza nam aplikacje do "robienia serwisu" - inaczej sobie to na poczatku wyobrażałem...
Warte przemyślenia

Nie powiem bo mnie zaciekawiłeś - co prawda tutaj opisujesz no nazwał bym to troszkę hard'corową sytuację bo jesli masz 20-30 trafien na sek to wiadomo oddać content 25x w sek - pryszcz - generować go 25x sek - schody...

ale w przypadku kiedy rozpatrujemy aplikację mającą być wizytówką strony firmowej - gdzie najczęściej właściciel - a jak chce pełny panel administracyjny - to czy gra jest warta świeczki i aż tyle na tym zaoszczędzę - smarty i inne silniki szablonow tez maja mechanizmy cachowania a zeby 30 razy tego samego nie robic - oczywiscie chodzi wolniej - ale przy normalnych ilosciach wejsc na strone - czy to bedzie mialo az takie znaczenie....

Chyba sie z tym przespię i pomysle na spokojnie

[TQM]

Jest prawie dokladnie tak jak mowisz. Smarty jest fajne i latwo sie w nim pisze. Jesli masz swoj wlasny serwer albo nawet hosting i chcesz postawic wizytowke - PHP powinno dac rade w zupelnosci nawet dynamicznie generujac ogromny, ciezki i bardzo skomplikowany content. Moje zastosowanie jest rzeczywiscie specyficzne i wiekszosc moich serwerow dostaje pomiedzy 500k a 1mln zapytan kazdego dnia - szanse ze przynajmniej na poczatku portal o Inkach bedzie mial taki ruch sa wydaje mi sie niewielkie (oczywiscie nie chce urazic autora watku bo o Inkach moja wiedza jest znikoma i mam nadzieje cos doczytac jak strona ruszy).

Patrzac realnie - ile blogow stoi na np Wordpress'ie? Tysiace... ale jesli hosting jest powiedzmy przecietny to mozna czekac kilka sekund zanim strona sie zacznie ladowac. Tego nalezy unikac. Jesli nie jestes w stanie dostarczyc strony < 3 sekund to ok 30% gosci odchodzi, 5 sekund i masz 50%, 7 sekund prawie kazdy daje sobie spokoj i wraca do google po nastepny link. Aktualna strona glowna na moim blogu zaladowala sie kompletnie z grafika w 0.686s, dlatego ze calosc jest statyczna. Gdyby mialo sie to generowac dynamicznie, czas bylby co najmniej 0.2-0.3s dluzszy, nawet do 2s dluzszy bo ten serwer jest dosc obciazony czasami :-P

I na zakonczenie co do CMS - ang. "Content Management System", zarzadza trescia ktora jest publikowana. Nikt nigdy nie powiedzial, ze tresc musi byc generowana dynamicznie przy kazdym odswiezeniu strony, prawda?
Najprostszy i zarazem perfidny 'ustatyczniony CMS' jakim sie bawilem - Wordpress na jakims tam komputerku, 'wget -r' i FTP plikow na wlasciwy serwer :-)



Ucieklismy off-topic - wracajac do strony o Inkach i w sumie serca tematu.
Pisanie wlasnego CMSa moim zdaniem nie ma sensu i podam ku temu powody:
1. kiedy strona zostanie uruchomiona jesli zaczniecie pisac wlasny CMS?
2. ile bedzie bledow w tym CMSie ktore umozliwia wycieki danych?
3. ile czasu zajmie opanowanie zagadnien bezpieczenstwa na poziomie ktory umozliwi napisanie w miare bezpiecznego kodu?
4. ile razy cos wycieknie ze strony zanim kod aplikacji zostanie zabezpieczony?

Tyle chyba wystarczy jako argumenty aby nie pisac wlasnego kodu jesli nie jest sie na prawde dobrym w te klocki (a zakladam ze znajac sie na historii plemienia Inkow nie koniecznie zna sie od podszewki kwestie bezpiecznego programowania).

Ja proponowalbym pojsc po jakis gotowy produkt. Nawet Joomla bedzie lepsza niz wlasny kod i wiem co mowie. Joomla owszem, jest dziurawa... ale regularne kopie trzymane off-site czyli nie na serwerze gdzie jest hosting i pilnowanie biuletynow i ciagle aktualizowanie jak tylko pojawia sie jakies latki to jedyna rozsadna droga (dotyczy nie tylko Joomli ale kazdego innego CMS'a oraz modulow i plugin'ow do CMS'ow - one tez maja bledy!). Ostatnio TYPO3 mialo sporo alertow dotyczacych bezpieczenstwa. Moze warto na to popatrzec?

Joomla prosta w obsludze i calkiem ladnie sobie radzi. Mozna nawet zamowic komercyjnie szablony ktore wykonaja ludzie ktorzy sie na tym znaja - masa ofert w sieci jest. TYPO3 nie uzywalem jeszcze ale mnie zaciekawilo, Drupal tez jeszcze zyje (co mnie troche dziwi ale ok - ma zwolennikow widac).
Nie ma jednego slusznego rozwiazania. Jaki soft autor wybierze taki wybierze, na pewno pisanie wlasnego CMSa to kosztowna pomylka :-/

[eMCe]

Co do kontetnu offline - tak jak mowisz odbieglismy od tematu - ale zainteresowales mnie swoimi argumentami na tyle że postanowilem sie tym pobawić w wolnym czasie a ostatnio jakos udaje mi sie go odnaleźć
Myslę ze popiszemy o tym w nowym temacie jesli bedzie ktoś zainteresowany - ja narazie pisze mala aplikacje - nie do konca statyczna ale ukierunkowana na statyczny kontent....

Natomist co do jomali TYPO3 itp...
Powiem tak - widział ktoś zeby czołgiem ścigać kieszonkowca ?
Wydaje mi sie jest ta - sorry za porównanie ale krowa - której wiekszość funkcji nie jest potrzebna - szukał bym czegoś mniejszego sprytniejszego i wydajniejszego, bardziej ukierunkowanego na to co nam potrzeba

Osobiście nie korzystam z wszelkiej maści CMSów - nie mogę polecić niestety niczego....

[dbname]

Cieszę się, mogąc to wszystko czytać

Zgodnie z przewidywaniami nie mam pojęcia o zabezpieczeniach kodu, a tym bardziej o pisaniu całego CMS'a od podstaw. PHP troszkę znam ale tylko na tyle by wstawić echo i include i to też pewnie wywoła błąd

Na dzień dzisiejszy wybrałem php-fusion v7. Jest prosty, łatwy i przejrzysty. Z każdą zmianą w serwisie robiona jest kopia bazy danych poprzez CMS oraz z serwera, pliki przechowuję na dysku.

Niestety zdarzają się też błędy w CMS'ie - mimo to czekam na poprawę ze strony twórców.

No i cóż, ruch jak na razie niewielki na stronie ale właśnie takiego się spodziewałem. Temat dość niszowy i niewiele osób jest zainteresowana jego zgłębianiem. Postanawiam nie czuć się urażonym

Pozdrawiam i dziękuję.

[lame]

Witam

Wyborem darmowego CMS przede wszystkim powinna decydować popularność, jeżeli CMS jest popularny, istnieje od dłuższego czasu, koderzy mieli czas na poprawianie kodu, łatanie luk, w przypadku tych najpopualrniejszych CMSow, Joomla, Wordpress, w samym jądrze znajduje się już bardzo niewiele "krytycznych" luk bezpieczeństwa, osobna kwestia to dodatki i moduły pisane przez społeczność, czasami przez hakerów celowo umieszczających w nich trudne do znalezienia backdoory, czy też zupełnie nieświadomie popełnione błędy..
Z pomocą powinna przyjść automatyczna aktualizacja, zadanie cron odpalane raz na jakiś czas, sprawdzające czy są nowe aktualizacje dla jądra i modułów, automatyczne ich pobranie i istalacja.
Taki system chroni przed script-kidde i botami na opublikowane luki.

W tym miejscu mozemy postawic sobie pytanie, na ile bezpieczeny na byc kod php
I jak bardzo obawiamy sie o wyciek danych, jeżeli są one aż tak cenne,
należy pomyśleć nad umieszczeniem ich na zewnętrzym serwerze z zainstalowaną tylko jedną usługą sluzaca do monitorowanej (limitowanej) komunikacji, pobierania i wysylania wyżej wspomnianych cennych danych...
Odziwo stosunkowo bezpiecznym i niedrogim rozwiązaniem może być vps z dedykownym ip

Można (a nawet trzeba) stosować bezpieczeństwo prewencyjne, oto kilka przykładów:
- Odpowiednie CHMODu plikow
- Odpowiednie ustawienia basedir i inncych dyrektyw php jak np. magicquotes
- Odpowiednie prawa uzytkownika bazy sql
- polaczenia ze sql wylaczenie z localhosta
- ModRewrite na url wycinający wszelkie proby sql injection.
- Uzywanie osobnej przeglądarki do zarządznia stroną, (ataki CSRF)
I jeszcze taki maly trik, jezeli serwer obsluguje php.ini, dajemy w php_file_append skrypt wywalajacy wszelkie proby sql injection ze zmiennych REQUEST oraz SERVER.
To powinno w 100% zabezpieczyć przezd sql injection, chyba to opatententuje ;D

Dalsze prace nad zabezpieczeniem cudzego kodu uważam za bezcelowe.
Jedyny sposób na 100% pewne php to pisanie samemu.

Całkowita rezygnacja z php, to dodatkowa pewnosc.
Odpowiedz mi prosze TQM, czy istnieje mozliwosc, ze w serwerze WWW, bedzie istniala luka, ktora pozwoli na jego efektywne zaatakowanie wyłącznie z racji uruchoamiania skryptów CGI? Innymi slowy, czy moze zaistnieć sytuacja, gdzie serwer zostanie zaatakowany bo znajdowal sie w nim teoretycznie niegrozny kod php, a wine ponosi za to serwer www (luka, błąd konfiguracji, cokolwiek innego), jednocześnie inna strona, na tym samym serwerze, tylko że bez php, nie bedzie mogła zostać zaatakowana.
Jeżeli tak to bardzo Cie prosze o opisanie przykładowego scenariusza.

Można pójść tropem wywoływania przez odwiedzających wyłącznie statycznych stron, mam na mysli to co TQM pisal o cmsie generujacym statyczne strony i wysylajacym na serwer.
Jednakże całkowita rezygnacja z php po stronie serwera nie wchodzi w gre.
Można by generować i zapisywać statyczne dokumeny po stronie serwera, kod php odpowiedzialny za 'zycie' strony zajdował by się za httm authem zrobionym z htaccessa (dzisiaj kazdy serwer to ma)
Nie tracimy profitów z wydajności jaką daje nam wywoływanie przez odwiedzających wyłącznie statycznych podstron, a jednocześnie aby uruchomić jakikolwiek skrypt php, trzeba przejść przez aurotyzacje z hasłem robiąna przez serwer www, czy to bedzie mniej bezpieczne niż ten staticCMS którego opisuje TQM ?
Jeśli tak to dlaczego? Prosze o przykładowy sceniariusz.


Pod WordPress'a napisano kilka modułów pozwalających na cachowanie, niestety nie testowalem ich więc się nie wypowiem.

Pozdrawiam i czekam na odp.

// edit
Jeszcze jedno odnośnie samego mechanizmu autoruyzacji AUTH i jego implementacji.
Niektore przelądaki maja paskudny zwyczaj przechowywania danych służących do autoryzacji nawet po zamknieciu i wyczyszczeniu cookie.

[TQM]

Sorry, nie bylo mnie pare dni... 10 dni w Polsce, CONFidence 2.0... a rano lece juz do siebie. Postaram sie wiec odpowiedziec zanim znowu znikne na nastepne 10 dni zaczynajac w przyszlym tygodniu.

Odpowiedz mi prosze TQM, czy istnieje mozliwosc, ze w serwerze WWW, bedzie istniala luka, ktora pozwoli na jego efektywne zaatakowanie wyłącznie z racji uruchoamiania skryptów CGI? Innymi slowy, czy moze zaistnieć sytuacja, gdzie serwer zostanie zaatakowany bo znajdowal sie w nim teoretycznie niegrozny kod php, a wine ponosi za to serwer www (luka, błąd konfiguracji, cokolwiek innego), jednocześnie inna strona, na tym samym serwerze, tylko że bez php, nie bedzie mogła zostać zaatakowana.
Jeżeli tak to bardzo Cie prosze o opisanie przykładowego scenariusza.

zaznaczylem pewien fragment...

genrealnie ja to widze tak - samo CGI nie jest dziura w bezpieczenstwie ale jesli serwer obsluguje CGI to musisz dokladnie patrzec na to co ten serwer moze uruchomic. CGI i PHP nie roznia sie niczym poza sposobem uruchomienia kodu... PHP najczesciej wystepuje jako modul ktory siedzi zaladowany w pamieci caly czas a CGI odpala sie jak jest potrzeba... ale PHP moze byc tez jako CGI lub FastCGI, Perl, shell, cokolwiek - moga byc jako CGI, FastCGI, Mason, itp itd. To tylko technologia ktora robi dokladnie to samo, sluzy do tych samych celow. Jesli nie dopilnujesz wiec co sie uruchamia, mozesz sie bardzo szybko zdziwic!

Luka - w serwerze - tuaj jasne, serwer na pewno zostanie zaatakowany i to najprawdopodobniej dosc skutecznie - jedynie kwestia czasu.
Blad w konfiguracji - jak najbardziej, wiele bledow w konfiguracji pozwala wyciagnac z serwera dodatkow informacje. Przyklady atakow - RFI, podniesienie uprawnien przez LFI, wbicie sie do bazy pomijajac serwer WWW (patrzcie co sie stalo z wykop.pl - wzorcowy przyklda za co powinno sie zwalniac ludzi), DoS, wyciekanie danych, itp itd - 99% tego to kwestia bledow w konfiguracji, najczesciej nieswiadomych.
Wez teraz takie PHP, mod_jakistam, mod_jakistam... jesli widze ze serwer ma tyle smieci i w jakich wersjach to moge sprobowac zaatakowac te dodatki a nie sam rdzen serwera - efek ten sam - najczesciej serwer ma nowego uzytkownika/admina o ktorym nikt nie wie (bo malo kto czyta logi) Nawet jesli serwer nie przedstawia sie tym jakie ma moduly dodane, to niektore z nich dodaja swoje wlasne naglowki gdzie nie tylko mowia ze sa zainstalowane ale nawet mowia w jakich sa wersjach albo z jakimi opcjami byly kompilowane.
Cokolwiek innego - no tutaj mozna jak zmiotka pod dywan, wszystko pozostale

Można pójść tropem wywoływania przez odwiedzających wyłącznie statycznych stron, mam na mysli to co TQM pisal o cmsie generujacym statyczne strony i wysylajacym na serwer.
Jednakże całkowita rezygnacja z php po stronie serwera nie wchodzi w gre.
Można by generować i zapisywać statyczne dokumeny po stronie serwera, kod php odpowiedzialny za 'zycie' strony zajdował by się za httm authem zrobionym z htaccessa (dzisiaj kazdy serwer to ma)
Nie tracimy profitów z wydajności jaką daje nam wywoływanie przez odwiedzających wyłącznie statycznych podstron, a jednocześnie aby uruchomić jakikolwiek skrypt php, trzeba przejść przez aurotyzacje z hasłem robiąna przez serwer www, czy to bedzie mniej bezpieczne niż ten staticCMS którego opisuje TQM ?
Jeśli tak to dlaczego? Prosze o przykładowy sceniariusz.

Moim zdaniem jest to jak najbardziej wykonalne ale bedzie mniej wydajne tak czy inaczej i nieco mniej bezpieczne. Mowiac o bezpieczenstwie mam na mysli, ze http auth nie szyfruje niczego tak na prawde i jest podatne na automatyczne ataki brute-force, trzeba monitorowac co sie dzieje i tyle bo to jedyna metoda, poza tym nadal na serwerze znajduje sie aplikacja wiec tak hmmm nie do konca jak dla mnie. Z kwestii samego istnienia tam PHP powstaja znowu kwestie wydajnosci. Jesli mamy modul zaladowany to zajmuje on pamiec, dalej w zaleznosci od konfiguracji moze okazac sie ze nawet zdecydowana wiekszosc plikow bedzie skanowana pod katem php zamiast byc serwowana jak leci - to jest dodatkowy czas procesora na kazdym zapytaniu, dodatkowa pamiec i nawet jesli nie odpalamy skryptu w php to sa dodatkowe elementy lancucha obslugi zapytania (powiedzmy ze to seria IF'ow) i to tez zajmuje czas. Ok - ja jestem nadwrazliwy jesli idzie o wydajnosc ale ja nie mam wyjscia obslugujac na jednej tylko sredniej wielkosci stronie ponad 5k GET'ow na sekunde gdy jest szczytowe obciazenie. Do domowych zastosowan kwestie wydajnosci na takim poziomie mozna prawie zignorowac.
Na dokladke dochodza bledy ludzkie - blad w konfiguracji serwera, dziura w oprogramowaniu, itd. Mozna sie zdziwic co ludzie potrafia zrobic majac nawet bardzo ograniczone informacje o platformie ktora maja zamiar zaatakowac!

Pod WordPress'a napisano kilka modułów pozwalających na cachowanie, niestety nie testowalem ich więc się nie wypowiem.

Hmmm wiekszosc tego co widzialem robi cache na plikach. Ok - wycina to czas na podlaczenie do bazy sql, zapytan, allokacji/deallokacji zasobow i generowania HTMLa i to juz moze dac baaardzo duzo! Dodaj do tego jeszcze cache kodu PHP juz w postaci bytecode'u i masz fajny serwerek... jednak nadal odpalasz PHP ktore odpala dodatkowa logike i sprawdza czy jest plik wygenerowany, pozniej leci I/O ktore jes IMHO najwolniejszym elementem calej konfiguracji i dopiero odsylasz dane z cache'a. Powiedzmy ze to takie rozwiazanie nieco powyzej 50% tego co ja bym uznal za na prawde dobre... ale hej - 50%+ niz 0% :-)

// edit
Jeszcze jedno odnośnie samego mechanizmu autoruyzacji AUTH i jego implementacji.
Niektore przelądaki maja paskudny zwyczaj przechowywania danych służących do autoryzacji nawet po zamknieciu i wyczyszczeniu cookie.

mozesz cos wiecej na ten temat? bylbym zainteresowany sprawdzeniem tych przegladarek i znalezieniem dlaczego tak sie dzieje bo to moze byc super ciekawe