Saját CMS

Internet: PHP, CGI, stb.

Sziasztok! Szeretném elfelejteni a Joomlát és az egyéb ingyenes CMS rendszereket. Szeretnék végre egy olyat amit olyanra csinálhatok meg amilyenre én akarom. Elég amatőr vagyok PHP és egyéb internet programozás terén. Ezért szereteném segítségeteket kérni, hogy milyen könyveket lenne érdemes megvenni ahhoz, hogy egy kis egyszerű CMS rendszert fel építsek aztán, persze mehetne a többi is, csak először az alapokat szeretném megtanulni. Szerintetek?

  • 9661 megtekintés

( hefti | 2009. 05. 20., sze – 15:46 )

tanulgass xhtml, css, php, mysql -t ez alap (van php fekete konyvem, de nemnagyon nyitottam ki). aztan guglizz sokat, rengeteg hasznalhato tutorial van.
gyakorlaskepp csinalj ezt-azt amig rajossz/belejossz dolgokba

-----------------------------------------
lowfast

( Aadaam v | 2009. 05. 20., sze – 15:48 )

Jajj.

Diszklemer: 10 eve hasznalok PHP-t. Az elozo evszazad ota... Sot,ezert fizetnek, nem is keveset.

CMS-sel kapcsolatban az az alapszabaly, hogy ne irj sajatot. Minek? Felesleges. Nem valoszinu, hogy profi szintre el fog jutni valaha is.

Inkabb probalj meg mar letezo CMS-ekbe modulokat fejleszteni. Ugyanis azok, akik mar 10 eve CMS-eket irnak, valoszinuleg tobbet ertenek a CMS-irashoz, mint Te, ertelemszeruen abbol a sajat kijelentesedbol kiindulva, hogy kezdo vagy.

Mikozben modult probalsz irni hozza, olvasod az o kodjukat, mert valahogy hozza kell tudni illeszteni. Sot, valoszinuleg megprobalod az o stilusukba irni azt a szegeny kodot.

Ha mindezt eljatszod 3-4 fele CMS-sel, keretrendszerrel (Joomla, Drupal, Typo3, mondjuk ez 3 nagy vonulat, keretrendszerben symfony framework, zend framework, cake php, ezeket is), eleinte kis modulokat, akar jatszasibol, kesobb komplett website-okat epitve bennuk, tobbet fogsz szerintem tanulni, mint pusztan a sajat kododbol. Persze kesobb lehet, kell az is, de eloszor masoktol tanulj, ne magadtol.

Egyetértek!!!
A fenti ingyenes CMS-eket nem kezdő tudással rendelkező php programozók fejlesztik. Mondjuk én szinte csak drupallal foglalkozok, lehet az is ágyúval verébre néhány esetben, de valahol a http://drupal.hu vagy http://weblabor.hu oldalon volt arról szó, hogyan lehet kiherélni a rendszert, talán még most is aktuális a cikk.
Lényeg lenne a biztonsági frissítések felrakása, figyelése az ingyenes CMS-eknél.
Itt egy fórum témám arról, milyen hibát lehet csinálni saját CMS rendszerrel: http://hup.hu/node/70648
A hibát még most sem javították, semmi hozzászólás, üzenet, hiába jeleztem a hibát.

Egyetertek.

Megtekintesre ajanlom: alfresco, ezen belul alfresco share, valamint a liferay portalban levo cms-t is.
Egyebkent amire te gondolsz, az talan nem is cms, hanem annal szukebb, WCM (Web Content Management). Na az Alfresco Share ennek a brutal megvalositasa. A Drupal ahhoz kepest egy jatekauto (enterprise vs. kkv). Persze a Drupal is jo cucc, a moduljaival nagyon jo dolgokat lehet megcsinalni, en is szeretem.
Egyfos csapatnak persze nem ajanlom az Alfresco-t, nem arra lett kitalalva :)
Csak azert irtam le ezeket, hogy van elet a php-n kivul is :)

--
Gabriel Akos

En nem azt mondom, hogy felesleges; azert amikor Felho CMS-irasba kezd, felkapom ra a fejem, de o az orszag egyik legjobb PHP-sa.

Lehet ujat mutatni ebben a temaban, lehet mas iranybol elindulni es jo helyre erkezni.

A legtobb baj viszont az autodidakta programozoknak azon valfajaval van, akik csak a sajat kodjukbol tanultak. Kell egy CMS-hez tervezesi, szoftveres, stb, tudas, ez igaz. Ritka esetben el tudom kepzelni, hogy ez osztonos. Azt is el tudom kepzelni, hogy annyira jo a megertokeje, hogy felszedi a tudast egyetemen, eloadas-anyagbol.

De igazabol azt gondolom, ha sok-sok-sok profi kodot latsz, akkor elobb-utobb erteni fogod, mirol van szo. Azokat probald meg utanozni.

En egyebkent evekig typo3-fan voltam, azt tanitottam, mert sikerult egy eleg altalanos gondolatmenetet, ertelmes adminfelulettel osszehozniuk. De ugyanakkor a legtobb ember mostanaban a - talan kevesbe objektumorientalt, de jobban hasznalhato - drupalra eskuszik.

Ez a ket rendszer ket durvan eltero gondolatmenetet takar, erdemes rajuk nezni.

Erdemes ranezni a Zend Frameworkre is, azon egyszeru okbol, hogy a Zend a PHP mogott allo ceg, es nagyon jo tudni azt, mit gondolnak a php alkotoi arrol, hogy kell hasznalni a nyelvet. En pl. nem hasznalok template rendszereket - a Zend_View template-rendszerenek lenyege 11 sor, egyszer talan meg a HUP forumaba is bemasoltam. a sajat, tomoritett valtozatomat.

Lehet, hogy az is eleg lenne, hacsak siman elolvasnad ezeknek a rendszereknek a kodjait, vegrehajtasi uttal egyutt (ez php-ban sokszor nem annyira egyertelmu szerintem), de talan meg jobb, ha utanozni probalod ott helyben a stilust, ezert mondtam, hogy irj sajat modulokat bennuk. Fogd fel az egeszet ugy, mint az (emberi) nyelvtanulast, hogy oke, tanulod a nyelvi szabalyokat, de melleje filmet nezel, olvasol, es orulsz, ha van kivel beszelgetned az adott nyelven. Na, ez is ilyen.

Egyértelműen a Drupal.

Okok:
1.) Biztonságos. By design védelem van az SQL injection ellen (bár lehet olyan kódot írni direkt), és a legtöbb támadásra is immunis.
2.) Ha kódot akarsz olvasni, akkor nagyon jól jársz vele: az egyik legtisztább kóddal rendelkező open source projekt. Nagyon szépen dokumentálva van minden függvény, és a core-ban lévő dolgoknak elég szigorú kódolási konvenciókat kell követnie (=> ugyanúgy néz ki minden kód, könnyű eligazodni). A core modulok pedig nagyon szépen körbejárják az API-kat.
3.) Rengeteg, nagyon jó minőségű dokumentáció (A Pro Drupal Development c. könyv musthave).
4.) Nagyon jól tuningolható, lehetetlennek tűnő szervereken is tudtuk emberi sebességre hozni.
5.) A core érintetlen marad. Semmilyen modul nem piszkál bele a core-ba, amit Drupalból ki lehet hozni, azt ki lehet hozni a core piszkálása nélkül is. (ez most lehet nem tűnik nagy dolognak, de az: sokkal egyszerűbb frissíteni, kevesebb a bug és a sechole így)
6.) Szinte mindenhez van modul már előre megírva.
7.) Nagyképű egoistáktól mentes közösség. Van 1-2 ember, de nem jellemző a túlzott egózás (hogy ez miért gond, lásd Ulrich Drepper "munkásságát"). Ez sem tűnik nagy dolognak, de hidd el, hosszű távon sokkal könnyebb egy nyitott közösséggel dolgozni, mint 1-2 idióta éppen aktuális agymenésének megfelelni.
8.) Egyre nagyobb pénz van benne. Nem egy olyan magyar Drupal fejlesztőt ismerek személyesen, akik nagy és komoly külföldi cégektől kapnak fizetést dollárban.
9.) A bleeding-edge webes technológiák könnyedén elérhetőek (a Drupal 7 már úgy fog jönni, hogy lesz RDFa támogatás a core-ban)
10.) A legkönnyebben a Drupal-t lehet jó helyeket elérni a keresőkben (SEO terén talán a legjobb CMS).

Próbáltam én is sokáig saját CMS-t írni, de belefáradtam. Hiába volt bármilyen fejlett, egyszerűen hiányoztak az API-k alóla, és minden funckió implementálása egy API megírásával kezdődött. Aztán sürgetett az idő (megrendelő), és sietni kellett vele, így nem tudtam a szép modularitást tartani, és bár nem fejeződött be a projekt, de biztos vagyok benne, hogy 1, max 2 év alatt teljesen karbantarthatatlanná vált volna. Nem éri meg saját CMS-sel vesződni.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

[off]
Deszeretem amikor megjon a marketing-reszleg... (Bocs, nem bantani akarlak szemely szerint, csak a nagy projektek koruli kultok akasztanak ki)

En a drupalt egy alultervezett rendszernek tartom, amit picit tulnyuzsognek, es ez a forraskod rovasara tud menni. De valamiert megis nepszeru, igy konnyen lehet, hogy en tevedek - valoszinuleg csak a node-alapu rendszer vette el a kedvem, amit nem feltetlenul sikerult mai napig teljesen felfognom, meg az adminja, amit nem mernek ugyfel kezebe adni, mert tok szep hogy generalt, csak otvarmod kenyelmetlen meg egysegsugaru szamara logikatlan tud lenni. Persze egymilliard legy nem tevedhet, meg ilyesmik, azert erdemes melle megnezni egy zend-et vagy symfony-t, mert tartok tole, nem a drupalbol tanulja meg a szep felepitest :) Tudom, izlesek es pofonok :)

Teny, a Typo se biztos hogy jobb, mert ott meg akkora nyakatekereseket kell neha csinalni, hogy az ember a fraszt kapja, ill. addig van jo napod, amig a hireket nem kell tudnod lekezelni, csak statikus oldalakat, meg kis, dinamikus modulokat, mert az nagyon szep benne, a hirkezeles borzalmas. Na es akkor meg a mindenki altal imadott TypoScriptrol egy szot se ejtettunk :) De OOP-bol egy csomot tanultam azon keresztul.

[/off]

Ez nem marketing :)

A Drupal marhára nem alul tervezett. Attól, hogy nem úgy kezdődik minden fájl, hogy class foobar, még lehet mögötte gondos tervezés. OOP és AOP szemléletű rendszer, csak a PHP nem alkalmas arra, hogy ilyen szintű rugalmasságot OOP eszközökkel ki lehessen fejezni.

Admin felület: Drupal 7-re áttervezik az egészet usability expertek bevonásával.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Nem nagyon vágom ezt az admin parát. Drupalba olyan admint csinálsz amilyet akarsz, külön template-ezhető és mint az köztudott drupalban a template-készítés nem feltétlen egyenlő egy index.php + style.css cserével (like joomla), és akkor nem is beszéltünk arról, hogy lehet (át)írni saját modulokat ahol/amibe szintén olyan admin opciókat tesz bele a jóember amit nem szégyell.

Ennek fényében szintén nem vágom, hogy a retkesbe jön ide a symphony/codeigneiter és társai ahol minden ilyenen a két kis ügyes kezünkkel illik végigmenni ill. ha más szutykait használjuk ugyanúgy kézzel átírni.

No rainbow, no sugar

"koztudott"

[off]
Te se latsz ki a drupal mogul talan?
[/off]

Biztos template-ezheto, en amennyit foglalkoztam vele, megegyeztunk egymas kolcsonos keruleseben a fenti parak miatt. Nyilvan van 20 000 rendszer, es nem fogom kulon template-ezni, ha ugy erzem, van olyan, ami az ugyfelnek kulon template nelkul is kezreall. Nem hulyultem meg..
Szabad piac van, mindegyik ugyanugy 0 ft-ba kerul.

A code igniter en se tudom, hogy jon ide, a symphony ugy, hogy van egy jol kikovetelt stilusa a rendszernek, amit a drupal sokezer modulja mennyisegi okok miatt nem kovet olyan szepen.

De a symphony nem CMS, hanem application framework. Dobbenetesen sok esetben arra van szuksege az illetonek, azert nyomom azt is. De ott is mondtam egy alternativat is, zend fw, es a cake php-t is csak azert nem emlegettem, mert marha messzirol lattam meg csak.

Azt nem vitatom, hogy PHP-ban nyelvi eszkozok gyengek, mondjuk AOP-t en kommentreflexioval oldottam meg legutobb tok szepen (beparsolom a getDocComment-et, es specko @tageket rakok bele), de lattam mar asszociativ tomb alapu, meg __call alapu megoldasokat is. Ettol meg neha dobtam hatast drupal modulkod minosegre, de errol nyilvan nem a drupal tehet.

Egy szo mint szaz, szerintem eloszor lasson valaki _sok_ rendszert, probalja ki minel melyeben _mindet_, majd utana kezdjen evangelizalni.

[szerk] diszklemer: ha jol emlekszem, 1 vagy 2 projektet toltam vegig drupal alappal, ezek 2-3 honapos lefutasuak voltak[/szerk]

Na varjunk, a cakephp-t aztan vegkepp ne keverjuk ide, mert az tenyleg csak egy framework (annak is eleg alap, bar nem rossz), konkretan a rails lenyulasa ugy, ahogy van - talan egy kicsit hozzaigazitottak a kevesbe dinamikus PHP-hez, de ennyi. Ahhoz, hogy az ember cakephp-ben tudjon dolgokat csinalni, sokkal nagyobb tudas kell, mint egy Tyop/Drupal/Joomla-hoz, mert ott az alapokat is neked kell lerakni.

Mondjuk eleve nem ertem, hogy jon a CMS-ekhez az app fw-k osszehasonlitasa, mert alma es korte, de ez mar az en bajom.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ez nem is valtozott tul sokat, ha jol tevedek. Ahol egy kozosseg meg tudja szavazni, hogy a visszaperjel nevterszeparator legyen, ott en mar igen erosen aggodnek. Persze, kell olyan is, aki a szellel szemben probalkozik a pontos celzassal, csak a nadragra azert vigyazni kellene...
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

+1

Ha a php tanulás elején 1-2 kisebb php+mysql oldalt csinálsz (látogató számláló, üzenőfal), azt meg tudod csinálni saját scriptekkel. De mihelyt ez túlnő 5-6 oldalra, vagy >50 felhasználót kezelő portálra, akkor általában jobban jársz, ha a saját scriptekről áttérsz egy CMS-re. Én 5 éve csinálok honlapokat, csak idén 2 honlapot rakok át Drupálra, és plusz egy még tervbe van véve. Egyrészt azért, mert a felhasználók most már megkövetelik, hogy ők is szerkeszthessék, másrészt meg sokkal kényelmesebb, ha ők szerkesztik :). Egy saját rendszer kifejlesztése rengeteg idő, amit nem konkrét megrendelésekkel töltesz (amit esetleg megfizetnek), hanem a saját rendszer tervezésével és megírásával.

Nemtom, én pl úgy vagyok vele, hogy leégne a bőr a képemről, hogy egy más által letölthetővé tett, ingyenes rendszerért pénzt kérjek, mert írtam hozzá egy kisebb modult és rátettem a designt...
Igaz, a saját CMS nem kis időt és energiát követel, de egy átlagos weboldalhoz nem is kell olyan nagyon bonyolult CMS szerintem. (hírek, letöltések, webshop, fórum)
A legtöbb megrendelő nem igényel full extrás admin felületet.

Tény, hogy énis azt javasolnám a topicnyitónak, hogy mielőtt saját fejlesztésébe kezd, ismerjen meg pár már létező CMS-t és tanuljon belőlük, majd pedig később ha már úgy érzi, hogy megvan a tapasztalata/ideje/lelkesedése, akkor vágjon bele a sajátba.

Én úgy vagyok vele, hogy kb ötödjére írom meg a CMS-emet, mostmár talán kezdi kiforrni magát, tanulva a korábbi hibákból. Én szeretem a kihívásokat. :)

Ugye az általad írt CMS nem ingyenes adatbáziskezelőt használ? Tessék azt is szépen 0-ról megírni, az is része a rendszernek, nehogy már ingyenes programért pénzt kérj a klienstől!
[ valami egyéb újító elképzelés az open source világban dolgozók egzisztenciájának megteremtésére?? ]

Jó, akkor fogalmazok másképp. A tudásodért, hogy az adott open source szoftvert a kliensnek megoldásként tálald és alakítsd, miért ne kérhetnél akár magas árat is?
Egy open source CMS-en alapuló oldal az nem csak annyi, hogy lecseréljük a logót és írunk két modult, jobb helyeken legalábbis.

Ok, végülis igazad van. A tudást is meg kell fizetni.
Ettől függetlenül én jobban örülök a saját fejlesztésemnek. :)
Arra büszkén mondhatom, hogy az a sajátom teljes mértékben. Mondjuk sokkal több erőfeszítést is kíván.

Az ingyenes CMS mellett szól, hogy elég sok dokumentáció/fórum van róla a neten, míg a sajátnál néha elfelejtheti az ember megfelelően dokumentálni. Ebből adódhatnak később nehézségek. :)

"de egy átlagos weboldalhoz nem is kell olyan nagyon bonyolult CMS szerintem. (hírek, letöltések, webshop, fórum)"

:)))))

Ne gondold, hogy nem tudnak egy webshopot túlbonyolítani, főleg, ha a marketing is képbe kerül ;)

Másik: valódi (értsd: nem otthoni hobbiprojektnél) nem érdekes, mennyire bonyolult, míg: kellően gyors, nem rohasztja le a szervert és megfelelően skálázható, és ami a legfontosabb: kellőképpen rugalmas az ad-hoc módon kitalált elmebeteg ötletek tegnapra történő implementálására is.

----------------
Lvl86 Troll

( gaabeesz | 2009. 05. 20., sze – 17:51 )

Az én véleményem, hogy használj egy ingyenes cms-t, és közben kezd el fejlesztgetni a sajátodat. Ha kitartó vagy, akkor elég a "Tanuljuk meg a php5 használatát 24 óra alatt" című könyv, letölthető pdf-ben, de a legjobb ha elmész egy könyvtárba és kikölcsönzöd. Kellő kitartással, és próbálgatással meg fogod tudni tanulni. Könyv+google, plusz ha windows alatt szeretnéd megírni akkor AppServ v*.*, nem tudom mi a legújabb verziója, van benne Apache+Mysql. De a legjobb lenne ha felhúznál egy linux-ot és az alatt tesztelgetnéd. Üdv!

"Ha kitartó vagy, akkor elég a "Tanuljuk meg a php5 használatát 24 óra alatt" című könyv"

Nem, nem nem és nem!

Az, hogy valaki ismeri a PHP nyelv szintaxisát, de nincs mögötte semmiféle programozói szemlélet és tudás, nincs mögötte algoritmusok, adatstruktúrák, tervezési minták stb. ismerete, attól még nem fog tudni (értelmes) rendszert tervezni, maximum egy nagy katyvaszt fog tudni egymásra hányni.

Szoftverfejlesztői tudás != PHP nyelv ismerete.

----------------
Lvl86 Troll

Ezekkel az xyz 24 óra könyvekkel ugyanaz a bajom, mint a számítógép és az egyszerű mezei földi halandó esetével: teljesen mindegy, hogy milyen rendszert tolsz elé, teljesen mindegy, hogy mennyire kézreállóra állítod be, ha a legalapabb fogalmakkal sincs tisztában, (pl. fájlkezelés), szenvedni fog vele.

Ugyanez igaz erre is: ezek a nyelvi ismertetők nagyon kevesek, ebből nem lehet megtanulni szoftvert fejleszteni. Egyébként talán ez az, amit legkevésbé vagy szinte sehol nem promotálnak/oktatnak: algoritmusokat, OOP alapokat elmondanak, jobb esetben beszélnek valamit arról, hogy hogyan kell(ene) kinéznie egy szoftver fejlesztés folyamatainak, de arról, hogy hogyan kell megtervezni egy szoftvert, arról nemsok.

Aztán persze, hogy terjednek az összegányolt szutykok..

----------------
Lvl86 Troll

"Ugyanez igaz erre is: ezek a nyelvi ismertetők nagyon kevesek, ebből nem lehet megtanulni szoftvert fejleszteni. Egyébként talán ez az, amit legkevésbé vagy szinte sehol nem promotálnak/oktatnak: algoritmusokat, OOP alapokat elmondanak, jobb esetben beszélnek valamit arról, hogy hogyan kell(ene) kinéznie egy szoftver fejlesztés folyamatainak, de arról, hogy hogyan kell megtervezni egy szoftvert, arról nemsok."

A 24 órás könyvek egyfajta alapozók - kezdők számára. Megismertetik a nyelv szintaxisát, a nyelv alapjait, esetlegesen bemutatnak pár tervezési mintát: és kész. Miért kéne több?

[Persze ebbe is van szórás mert ha az Apress féle "Beggining PHP and Mysql"-t nézem a maga 1100 körüli oldal terjedelmével és 2 kilós súlyával akkor az alapozás kérdése igenis lehet alapos. (És még csak az első a sorozathoz tartozó könyvek között, van még utána 4-5).]

Ezek a könyvek egyébként annyiban már jobbak az elődeiknél, hogy azért megpróbálják felnyitni az egyszerű halandók szemét az általad hiányolt dolgokról és pl. a sokat hivatkozott PHP Black Book-kal (ami a hülyeségeit leszámítva egy jó könyv) ellentétben nem próbálnak ráerőltetni egy rossz tervezési mintát az emberekre.

Akit jobban érdekel az úgyis vesz a témához vágó könyveket illetve szintet ugorva még jobban belemerülhet a témába (ezekhez is tonnaszám vannak könyvek).

No rainbow, no sugar

Nyílván, nem egyenlő, de ahhoz, hogy elkezdje nem rossz szerintem, mivel vannak benne egyszerű kis példák, ami alapján érthetővé válik a legalapvetőbb függvények használata, pénzt én sem adnék érte, de egy nagyon kezdőnek emészthető a tartalma. És egy pár oldalas weboldalt össze tud dobni belőle. Nyílván egy portál/saját cms megírásához jóval több kell, én csak kezdésnek ajánlottam.

Te azt mondod fud, én azt mondom hype.
Ez is olyan vicc mint ez: https://www.szszi.hu/ojoteclient/
Az a lényeg hogy átment a w3c validatoron mi?
Nem várok sokat egy olyan CMS-től ahol sokáig segédtáblákkal oldották meg az auto incrementet. Attól hogy valami megfelel a saját elvárásainak...

sokáig segédtáblákkal oldották meg az auto incrementet

Igen, mert akkor (mocsokregen) a mysql mittomenmelyik adatbazis engineje nem tamogatta az auto incrementet, es ezt nekik szem elott kellett tartani (te komolyan azt gondoltad hogy azert volt igy mert nem tudtak volna megcsinalni?).

Most akkor azt is mondanad hogy te nem varsz sokat egy olyan adatbaziskezelotol ahol sokaig nem oldottak meg az auto incrementet?

Mellesleg nem segedtablakkal, hanem csak eggyel.

Már mocsokrégen nem volt technikailag indokolt az ilyen ortopéd módszer, ne kelljen ötször leírnom ugyanazt, ne kelljen bizonygatnom hogy korrektül fogalmaztam amikor azt írtam SOKÁIG volt így, ne kelljen a rágalmaidat cáfolnom, miszerint személyeskedésbe váltunk, mert részemről nem volt ilyen szándék, ellenben te kötözködsz. Miben adjak igazat? Tök mindegy mit írok véleményként, úgyis belekötsz, mintha ezen múlna a jókedved, igazat adni csak érvekre alapuló vitában lehetne. Hol kéne látnom technikai érveket? Nevetséges vagy.

Leirtam hogy miert hasznaltak segedtablakat. Cafolj ra hogy nem volt jogos es szukseges hogy igy tettek, vagy a fenti erved semmit nem bizonyit.

ne kelljen a rágalmaidat cáfolnom, miszerint személyeskedésbe váltunk, mert részemről nem volt ilyen szándék
VS
Hol kéne látnom technikai érveket? Nevetséges vagy.

Ez most akkor hogy is van?

Bocsi, de látszik képben vagy... anno ezt a döntést azért hozták meg, mert több adatbázis-kezelő nem támogatta az "auto increment" használatát, és így nagyobb esély volt rá, hogy a jövőben több adatbázis-kezelőt lesznek képesek támogatni. De az idő nem erre haladt, kompatibilitási okokból még tartották egy ideig, majd megszüntették ezt a módszert.
Amúgy egy táblával, korrekt módon megoldották. Az pedig, hogy mit fejlesztenek egy rendszerrel, nem feltétlenül magát az eszközt minősíti.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( zolti v | 2009. 05. 20., sze – 20:29 )

Én 5 éve akartam egy sima weblapot összedobni saját célra. Gondoltam egy hónap és kész. Így is lett azóta is ugyanúgy néz ki mint akkor, viszont 2 évig minden szabadidőmben ezt fejlesztettem tovább. Még utána 1 évig néha néha belepiszkáltam, de azóta nem.
Az eredmény az, hogy van egy saját motorom ami nincs befejezve, nincs ledokumentálva és van hozzá 2 oldalnyi todo list(ez csak az amit nekem sikerült elkapni hibalista stb ,sql injection is van közte), valamint csak én tudom kezelni.
A PHP-vel ezen a projektten keresztül ismerkedtem meg. Sokáig gondolkoztam rajta, hogy folytassam -e (előröl kéne kezdenem az egészet az alapoktól) vagy ne.
Én most tartok ott sokkal jobban járok, ha megnézem a Joomla extension készítés doksiajit és áttérek a Joomlára saját kiegészítőkkel. És nem fog fájni a fejem a biztonság miatt.
Egyszerűen túl nőtt engem ez a projekt, még kész sincs de már rég felemésztette minden időmet.

A biztonság is egy relatív fogalom.
Az én saját CMS-emhez képest igencsak biztonságos egy extension nélküli Joomla.
Mivel kénytelen leszek saját extensiont írni hozzá, így már persze sok hibát ejthetek a szerintem megbízható motoron.
Egyenlőre nyitott vagyok még a Drupal felé is csak pár hónapja láttam valahol egy magyar nyelvű leírást a bővítményekről (amit most nem találok) és akkor fogalmazódott meg bennem a fenti gondolat.

( janoszen v | 2009. 05. 20., sze – 20:28 )

Picit ellent mondanék a többieknek. Ha jól tudsz programozni (az átlag f/os CMS fejlesztőnél jobban, akkor írj saját rendszert. Ellenben, ha nem tudod hozni a szükséges szintet, Joomláról válts Drupalra, műszakilag ugyanis fényévekkel jobb.

( MysteryKe | 2009. 05. 20., sze – 23:27 )

Én is főleg a biztonság miatt szeretnék én is saját CMS-t, mert hogy lehet biztonságos valami, ami nyílt forráskódú? Ami szinte nyitott könyv a támadók számára biztonság szempontjából? Ezekben a rendszerekben így csak az nem fedezi fel és használja ki a biztonsági réseket, aki nem akarja.
Egy nem publikus forráskódú rendszeren meg kicsit jóval nehezebb felfedezni a réseket.
Nem vagyok ellene a nyílt forráskódú programoknak, mert nap mint nap használom is őket, de ezen még komolyan senki nem gondolkozott el? Oké, hogy így mindenki tudja fejleszteni őket, de ugyanígy kiismerhetik őket a támadók is.

.... vagy elkalandoztam és ez inkább egy másik topicba való? :D

"Én is főleg a biztonság miatt szeretnék én is saját CMS-t"

Ez csak akkor jo erv, ha security temaban profi vagy, ami a hozzaszolasodbol - hogy is fogalmazzak finoman - nem latszik egyertelmuen.

"Egy nem publikus forráskódú rendszeren meg kicsit jóval nehezebb felfedezni a réseket."

Probalkozz meg vele egyszer, meg fogsz lepodni. :)

"Nem vagyok ellene a nyílt forráskódú programoknak, mert nap mint nap használom is őket, de ezen még komolyan senki nem gondolkozott el? Oké, hogy így mindenki tudja fejleszteni őket, de ugyanígy kiismerhetik őket a támadók is."

Altalanossagban nezve a zart forrasu dolgok is ugyanugy megismerhetoek (max. egy IDA pro licensz kell hozza), a webes cuccok meg egyebkent is elmondanak mindent magukrol.

Ez az erv maximum valami custom szerver-oldali app-nal lehet jo, ahol tenyleg kellemetlen 628-adszorra is kiprobalni az unicode dekodolas helyesseget az IDS-ek rosszallo pillantasai kozepette - de a vedelmi strategiat itt sem erdemes erre alapozni.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

"Csak azt mondom, hogy nehezebb kiismerni valaminek a működését, amihez nem adnak dokumentációt és nem hozzák ezüst tálcán eléd a forráskódját :)"

Ertem en, de ettol meg nem lesz igaz.
A webes sebezhetosegek legnagyobb resze gyonyoruen megtalalhato blackbox testing-el, a mukodes kiismerese nelkul - ilyen korulmenyek kozott pedig nem ez a helyes vedelmi strategia, hanem a biztonsagi hibak szamanak minimumra csokkentese, pl. azzal, hogy egy sokak altal alaposan ellenorzott rendszert hasznalsz.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

alaposan ellenőrzött, majd a javítás publikus és így szintén publikusak lesznek az újabb rések. Ha valami publikus, az nem biztonságos. Persze az sem teljesen biztonságos, ami nem publikus, de legalább nem adom oda a kulcsot a betörőnek (önként és dalolva). Kicsit nehezebb munka így megszerezni valamihez a hozzáférést.... (ismétlem: nem azt mondom, hogy lehetetlen)

Eleve kezdjuk ott, hogy a webes vilagban olyan, hogy zart forras, csak nagyon sok megkotes mellett letezik. Peldaul a HTML, a CSS, a JS nem titkolhato el a kulvilag elol, ezek mukodesebol pedig nem olyan nehez kovetkeztetni a mogottes kiszolgalo kodokra annak, aki erre szakosodott.

Arrol nem is beszelve, hogy a free webappokat sem a forraskod bujasaval torik fel, pont azert, mert nem lehet egyertelmuen tudni, hogy az eppen futo rendszeren ez vagy az a hiba nincs-e patchelve zart, belso patchel. Altalaban minden oldalt blackbox alapon tornek meg.

Arrol nem beszelve, hogy mitol lesz a te kodod biztonsagos? Azert mert te ramondod, hogy biztonsagos? Biztos, hogy tetelesen tudsz az osszes hibarol, amit a kodban elkovettel? Erre mar elore mondom a valaszt: nem. Ugyanis, ha nem egy hello world-szeru dolgot irsz, egyszeruen lehetetlen minden hibalehetosegre pontosan odafigyelni, lehet egy kazal hiba, ami egyszeruen nem jon elo teszteleskor, az eles rendszer mutatja meg a rendszer hibait.
Tessek megtanulni, hogy tokeletes program nincs. Egyszeruen nem lehetseges annyira atnezni valamit, hogy hibamentes legyen, tuti, hogy marad benne valami.

Azt mar meg sem emlitem, hogy a futtatokornyezeted is lehet bugos. Es akkor loszart se ersz azzal, hogy agyontesztelted a portalodat.

Az opensource cuccok pont azert tudnak jok lenni, mert ott kenyszerito ok van erre, mivel rengetegen hasznaljak. Van annyi hacker a vilagon, hogy nagyon gyorsan kiderulnek sebezhetosegek, es ezekre szuletik is fix.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

basszus, hát hiába tépem a számat?.....

Ismétlem: Nem azt mondom, hogy a kódom teljes mértékben és 100%-ban hibamentes, csak éppen nem tárom ki a nagyvilág elé, hogy mik a hibái, nem nyújtok a kódjához teljes hozzáférést (!!! azaz csak minden igazán lényeges dolgot megírok PHP-ba és csak a felületre vonatkozó dolgokat írnám meg JavaScriptben vagy egyéb más szkript-nyelven!!!), már ezzel is védem (valamennyire) a "rendszert".
Ezen mi nem érthető?
Meg letiltom a szerveren, hogy infókat adjon ki saját magáról (phpinfo() és a webszerver egyéb információs eszközei), már ezzel is nehezítve a támadó dolgát, hogy megtudja, hogy milyen framework fut rajta vagy hogy melyik verzió, így.

ÉS ismétlem, nem azt mondom, hogy semmit sem lehet feltörni, csak ha a valamiről nem adok ki teljes dokumentációt, teljes forráskódot, már ezzel is megnehezítve a támadó(k) dolgát.
Nem ismerem a blackbox technikát, éppen ezért nem tudok ahhoz hozzászólni, de nem is erről szól most a topic.

A másik meg az opensource cuccok fejlesztése...
Ismétlem: értem, hogy amit rengeteg ember fejleszt (több szem többet lát), abban kevesebb a biztonsági hiba, de ugyanígy nyitott könyv a támadók felé is és nem csak a fejlesztő(k)/felhasználók felé. Ezen mit nem lehet érteni??
Ha a betörőnek nem adod oda a lakáskulcsodat, akkor nehezebben fog bejutni a lakásodba a 12 ponton biztosított biztonsági ajtódon (ez sem lehetetlen, ha elég ügyes, csak nyilván időigényesebb, mint ha kulcsot másoltatnál neki).
Nyilván, ha másokban megbízol és nem fognak visszaélni az általuk fejlesztett programrészekkel vagy akár mások, mások által fejlesztett programrészekkel.... de azt az egyet megtanultam, hogy az életben csak magadban bízhatsz :)
Azaz, felfedezel egy általad észlelt hibát, jelzed, és vagy te, vagy más csinál egy patch-et, közzéteszi, ami szintén publikus lesz a támadó számára is, azt a patchet mindenki jól felteszi magának, a támadó kibogarássz a kódot, amit szinte ajándékként nyújtottak át neki, felfedez benne egy másik hibát, és jól kitudja használni azoknak a rendszereknek az újabb biztonsági hibáit, amit a patch okozott (kijavítasz valamit, akkor tuti biztos, hogy akkor fel lehet törni azt másképpen is), és így tovább és így tovább..... és ennek sose lesz vége.
Tehát nem megyek oda egy vadidegenhez az utcán, hogy "nesze b***meg, itt a lakáskulcsom, nem ismerlek ugyan, de ha éhes vagy nyugodtan ugorj fel hozzám, csak légyszi ne pakold ki a lakást..." ja és nem tájékoztatom arról, hogy hány ponton van biztosítva az ajtóm...
Szóval érted, hogy kb. mire gondoltam.
Amit én fejlesztek, azt én ismerem, már ezzel is nehezítve mások dolgát és nem kiáltom világgá, hogy hogyan is működik. Aki ügyes, az rá tud jönni, hogy hogyan is működik.

Elárulok egy szakmai titkot: egy oldal biztonsági hibáinak felderítése nagyon ritkán kezdődik kódelemzéssel. Először valami szkript végigszalad az URL-eken és a formokon, aztán ott próbálkozik SQL/XSS injection kereséssel. Itt a customphp-s szutykok 99% elvérzik.

A Drupal esetén meg azért is irreleváns marhaság amit írsz, mert ott több rétegű automatikus tesztelésen megy végig a kód. Érdemes Berry Jaspan után olvasgatni, ő mindenféle sechole kiderítését segítő patchekkel megtuningolt PHP-t használ, és azzal keres hibákat.

Mi is az URL-je egy olyan oldalnak, amit a te szuperbiztonságos motorod hajt? :)

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

amit a nagykozonseg ele szan, nem bizik meg a sajat munkajaban sem.

Akkor nalam nem 'altalaban' van. Szamomra a sajat munkamban megbizas elso korben azt jelenti, hogy a sajat eszkozokon is azt hasznalom. Mondjuk en nem cms-ben utazom, de a clapf es az mfha eles kornyezetben futnak nalam, ezert merem a nagykozonsegnek is ajanlani.

SPAMtelenul - POP3 spamszuro szolgaltatas

En nem teljesen igy ertettem. Az egy dolog, hogy magadnal is azt hasznalod, mert en is igy vagyok vele, azonban nem mondja az ember azt, hogy az en munkam csak tokeletes lehet, es biztonsagi problema mentes. Tuti, hogy vannak benne ilyen problemak, es csak remelni lehet, hogy elobb talalja meg az ember ezeket, minthogy kihasznalnak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Masszív és frissen tartott automatikus elemzőrendszerrel nem csak a customphp-s szutykok vérezek el már az első körökben... Egyébként láttam már nagy, zárt forráskódú rendszert, ahol az egyik modul az összes telepített komponens részletes verzióinformációját by default beletette némelyik, általa generált html-oldal forrásába megjegyzésként -- ez után érdekes volt blackbox tesztnek tekinteni a vizsgálódást...

Nem kell a lakáskulcsot odaadni egy hozzáértőnek, sőt, semmit sem kell a záradról elmondani neki, a 12, de a 1234 ponton záródó ajtónál is azt szokás elfelejteni, hogy szumma egy, azaz egy darab zárbetét az, ami az egészet mozgatja. A 12, 123, vagy 1234 darab rögzítés az a befeszítés ellen véd (úgy, ahogy, kerete válogatja...), márpedig az ilyen ajtók esetén ennek a támadásnak a legkisebb az esélye. Az eredeti kínai zárbetét egy erre specializálódott szakinak rossz esetben 10-12 perc, egy Abus, vagy Cisa (nem, nem az a cisa...) felső- vagy középkategóriás az azért tovább tart, annak ellenére, vagy épp azért, mert a működésről, kialakításról elég komoly ismeretei vannak -- első kézből.

Ha webes alkalmazást csinálsz, akkor annak a publikus inputjából/kimenetéből, post/get dolgaiból, sütijeiből elég jól lehet következtetni a mögötte lévő megoldásokra -- fogalmazzunk úgy, hogy volt szerencsém olyan környezetben dolgozni, ahol hivatalból ezzel foglalkozott néhány kolléga. Általában elég volt a blackbox teszt a feladatban szereplő rendszer sérülékenységeinek (vagy azok egy részének) a kimutatására.

"Én is főleg a biztonság miatt szeretnék én is saját CMS-t, mert hogy lehet biztonságos valami, ami nyílt forráskódú?"
Úgy, hogy biztonságosra tervezik. A zárt forrású CMS-ekben is nagyon könnyű hibákat találni (csak kicsit körülményesebb jó exploitot csinálni), a legtöbbje SQL injection ellen sincs védve (főleg a hidden form mezők), advancedebb támadási módokról meg nem is hallottak (sessionnal való betyárkodás és társai).

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Nem csoda, hogy a Joomla után ezt mondod. De amit Te szeretnél, az a "security by obscurity" elv, ami alapvetően hibás. A programodnak úgy kell működnie, hogy ha bárki a jelszavak kivételével megszerzi a kódot, akkor sem tud betörni. Szépen meg lehet ezt csinálni, még csak azokat az orbitális varázslásokat sem kell elkövetni, amit egyesek szoktak (jelszót kétszer hashelni, session-mágia, stb).

Amiért webfejlesztés terén falhoz állítanék legszívesebben 1-2 embert, azok az SQL injectek és XSS-ek. Egy jól megtervezett rendszerben ilyenek nincsenek, mert az adatbázist ugye elfedjük, a kimenetnél meg kódoljuk az entityket (HTML esetén).

Mint írtam, ha Te jó vagy (a jó ott kezdődik, hogy összeraksz egy blogmotort adminfelülettel, mindennel együtt maximum 2 nap alatt úgy, hogy fejleszteni lehessen bele és nincs vuln) akkor megéri Neked sajátot fejleszteni. Ha nem vagy jó, akkor maradj a F/OSS-nél.

( zsoc | 2009. 05. 21., cs – 08:51 )

Egy próbát mindenképp megér, már csak a fejlődés végett is. Viszont nem szabad elhamarkodni. Mindenképp szükséges némi elméleti anyagot felszedni, és nem csak programozás terén, hanem a biztonság, felhasználhatóság (usability), és dizájn tekintetében is, hacsak nem állsz össze egy builderrel.

Ezer meg egy CMS van a világon, Ha sajátot írsz mindenképp arra kell törekedni, hogy azokat a feltételeket teljesítse, amivel te tudsz jól dolgozni, mert rajtad kívül legfeljebb az fogja használni, aki majd valamikor talán megveszi.

Sok szerencsét hozzá.

--
http://blog.zsoc.net | http://trustno1.hu | http://www.runatabor.com
Born to be alive!

( kisg v | 2009. 05. 21., cs – 09:50 )

Én is azt javasolnám, amit a többiek: ne kezdj el 0-ról sajátot, hanem használj meglévő rendszert.

Be is kapcsolódhatnál valamelyik open source CMS fejlesztésébe. Ha jól tudom a Drupalnak magyar az egyik fő fejlesztője, tehát akár a nyelvi nehézségek is minimalizálhatók.

Például azt olvastam, hogy a Drupal 7 fejlesztése lelassult (van ahol azt írták "stalled" :) ), tehát valószínűleg szívesen vennének egy ifjú titánt aki szeretne besegíteni. Ha jól beletanulsz, és kicsit ismertebb lesz a neved, nem győzöd majd a projektajánlatokat visszautasítani. :)

Ha mégis "zöldmezős" fejlesztésbe kezdesz, akkor csak valamilyen jó frameworkkel. Én kettőre hívnám fel a figyelmed:
1. Zend Framework = tipikus Web MVC framework, gyakorlatilag minden nyelvhez van hasonló, tehát ha ezt megismered, akkor sokkal könnyebben tudsz majd más nyelven (pl. Java vagy Ruby), de hasonló techológián alapuló projektekbe bekapcsolódni.
2. Doctrine ORM = nagyon kényelmes eszköz az adatok tárolására. Szintén, ha megtanulod, a megszerzett tudást tudod majd hasznosítani más projektekben, mert a legtöbb ORM framework nyelvtől függetlenül ugyanezeket a mintákat követi.

Nekem az a tapasztalatom, hogy a hatékony fejlesztéshez 2 dolog biztosan kell:
1. Fejlesztőkörnyezet: IDE (kódkiegészíŧés, debugger), automatikus tesztkörnyezet (phpunit), statikus forráskódellenőrzés (phpcs), continuous integration server (Hudsont javaslom, phpUnderControl-tól menekülj :) ), api dokumentáció (phpdoc).

2. Code template: Ez alatt azt értem, hogy tervezd meg a kód struktúráját (ha pl. Zend Framework-öt használsz, akkor sok mindent már kitaláltak helyetted), és készíts egy template-et, hogy a függvényeid/metódusaid/osztályaid hogyan nézzenek ki, különös tekintettel a következő szempontokra:
- előfeltételek (assertion)
- hibakezelés (beleértve a felhasználó felé irányuló hibaüzenetek elválasztását a rendszer által generált üzenetektől)
- naplózás

Ha ezt kialakítod, dokumentálod, és konzekvensen alkalmazod, akkor megtettél egy jelentős lépést a jól karbantartható kód irányába.

Persze ez még csak a kezdet... :)

Üdv,
Gergely

Drupal 7: nem lassult le, nyár végéig nyitva a merge window. Elég sok API-t újraírtak (pl most már ORM az adatbázisréteg), ezért portolni kell a meglévő modulokat az új API-kra. A testbed (egy halom simpletest teszten megy át egy patch, mire egy core fejlesztő elé kerül review-ra) is lassítja a fejlesztés ezen szakaszát, de legalább eliminálva van a regressziók nagy része.

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Akkor nem osztogattak, hanem fosztogattak. Éljen az internet. :)

Azt lehet tudni, hogy miért nem pl. Doctrine lett az ORM, hanem ez a DB:TNG nevű? Van értelme ORM-ből sajátot fejleszteni? Vagy ez volt előbb és a Doctrine később? Van a DB:TNG-nek valami speciális tulajdonsága, ami miatt jobb?

Üdv,
Gergely

Szerintem az a mondat hogy Development for Drupal 7 has stalled. az arra vonatkozott, hogy az o projektjenek (a Vocabulary index) a fejlesztese allt le drupal7re.

Szoval korulbelul: The Vocabulary index development for Drupal 7 has stalled.

A drupal7 nagyon is fejlodik, aggodalomra semmi ok =)

( wladek1 | 2009. 05. 21., cs – 14:17 )

Szerintem bátran kezdj bele!
Nekem hasonló okokból lett elegem az e107 -ből, és csillió más cuccból.
A sajátomat én ingyen terjesztem az ismerősök közt (közlöm a korlátait is a rendszernek), ki van próbálva sok különféle helyzetben, sőt, épp ezek világítanak rá arra, milyen irányba is kell eltolnom a dolgot; mikre van szükség, stb. Ugyanígy kapják a frissítéseket is, persze...
Magam részéről nem foglalkoztam a design -el, arra ott a freecsstemplates.org; ellenben a biztonságra és a működési hibák kiküszöbölésére megpróbálok minnél nagyobb hangsúlyt fektetni.
Töviről-hegyire ismerem a működését, bármely hiba okozója hamar ismertté válik, stb.
Tegyem hozzá, hogy nyilvánvaló dolgokat soha nem kezdenék lecserélni, mint pl. FCKEditor, DOMPDF, Prototype + Scriptaculous.
Ugyanakkor rengeteg tudást és ismeretet tudsz felhalmozni.

szürkehrteg
azenoldalamponthu

Arra gondoltam, hogy vagy a P, vagy a W betüknél keresed majd. :)
(Nem volt kedvem kiirni mindent név szerint...:))
Egyébként, csak hogy mennyit lehet tanulni hibakezelési, stb szempontból, azt jól példázza az, amit itt felsoroltam.
Noha vannak benne triviális dolgok is, "hatalmas eredményként" feltüntetve, de az _önálló_ megvalósítás nagyon sokat jelentett nekem. Azt akartam, hogy működjön, s azt, hogy lehetőség szerint a saját igényeimet (illetve amit másoknál látok felmerülni) teljesítse, de nem kell tudjon olyat, amit a kutya nem fog használni. (Ez is a bajom a túlhízott CMS -ekkel)
Pl: ssl módban engedem alapértelmezetten az adminisztrációt, viszont kitörölhetem az ssl -el is, ha nem fut le legalább egy 

session_regenerate_id()

, közvetlen ssl módba váltást követően (hisz addig már bárki megszerezhette a session cookie -t).
Amúgy szívesen átadom a legutóbbi forrást (legelsőt nem, mert ma megnéztem, s felvonyítottam a röhögéstől :)), ha bárki dob mailt a wladek kukac wladek pont hu címre.

szürkehrteg
azenoldalamponthu

Session lopás ellen jó védelem, ha eltárolsz adatokat a kliensről (el szoktam menteni az IP-t és az user agent-t) és ellenőrzöd a session újraindításakor, hogy egyezik-e. User agentet mondjuk könnyű megbuktatni, IP-t már nehezebb, de annak is vannak buktatói (NAT-olt és/vagy proxyzott háló, terheléselosztó a webszerver előtt, stb.)

----------------
Lvl86 Troll

Köszi, hasznos infó...
Szerk:

Ha ezekből összerakva csinálsz egy md5 hash -t, és összehasonlítod, az is jó módszer ugye? Mert egy helyen csináltam ilyesmit. (Bár lehet felesleges a md5 használata ebben az esetben...viszont sessionban eltárolni egyszerűbb/szebb.)

szürkehrteg
azenoldalamponthu

( willy v | 2009. 05. 21., cs – 20:46 )

Bocs, van türelmed 3-4 évig, míg elkezded?

( efezus | 2009. 05. 22., p – 08:32 )

Na, most akkor a sok okos biztos leszedi a fejem, de azért csak irok ide a WordPress-ről, mivel ezideáig mindenki csak a többit emlegette.

Először is: a PHP alapok kellenek és fontosak szerintem is. Olyan kódot, mint a "nagyok" egyedül képtelen leszel irni (én sem tudok :) ). A már meglévő CMS-ekben lévő objektumok úgy vannak megirva, hogy egy raklapnyi ellenőrzés lefut. Erről már irtak előttem. Ezért kell ezeken keresztül hozzányúlni mindenhez, ha elkezdesz egy CMS-t használni. Ezt is meg kell persze tanulni, de megéri.

Typo3
Azt elfelejtette irni bárki is, hogy a Typo3-hoz - legalábbis,amikor én használtam - meg kell még tanulni a typoscript-et is, ami az egész elé odacsücsül. MINDENT meg lehet benne csinálni, user/jogosultság kezelése mellett elbújhat az összes többi CMS, de szerintem ezzel kezdeni az nagyon-nagyon durva.

Joomla
Kicsivel jobb, de túlságosan sok olyan dolog van benne, ami egy induló emberkének felesleges, szerintem. Plusz rohadt összetett a kódja ennek is. A doksi az használható, jó leirás van az osztályokról, metódusokról, stb., de akkor is nagyon küzdősnek érzem. Plusz egy kezdőnek ami a fontos, az ingyenes, de _szép_ sablonok kérdése elég gyerekcipőben jár. Tudom, nem ez a legfontosabb dolog technikailag, de aki először kezd el ilyennel foglalkozni, annak fontos lesz ez is.

WordPress
Ami miatt én szeretem a WordPress-t az a kicsi, kompakt volta. Sokkal jobban átlátható első nekifutásra, mind a Joomla, ez kezdőknél szerintem, vitális. Nem fogja elvenni a kedvét az osztályhierarchia megtanulása, függvényeket kell paramétereznie és ezek meg gyönyörűen le vannak irva a Codex oldalakon. Kicsit a dokumentáció átláthatósága is jobban tetszik itt. Rengeteg fejlesztői példa van már _eleve_ beépitve a Codex-be, kiragadott kódokon magyarázva egy-egy függvény paraméterezése, nagyon könnyen tanulható/használható/megjegyezhető. Tetszik az is, hogy a sablonfileok több darabból állnak, funkcionalitás szertint nagyon gyorsan meg lehet bennük találni mindent. És ahhez szinte konyhakész sablonokat lehet találni, van ingyenes és van fizetős is, amiket - szerintem - nagyon könnyen át lehet irni. Én egy ismerkedőnek inkább ezt ajánlanám...

eFeS
http://infoblog.tatrai.hu

Hátnemtom.

A Joomla elmebeteg módon akar mindenhova, mindent írni meg csomagmenedzselni, amitől idegbajt szoktam kapni. E mellett a bónusz, hogy rendszeres benne az XSS és más durva remote bug.

A wordpress pedig lehet, hogy kicsi, de ha kicsit is forgalmasabb az oldal, akkor igencsak meg tudja húzni a szervert még úgy is, hogy valami bájtkód kess van a php-ban. Talán egy fokkal jobb remote bug téren, mint a Joomla, de ezzel együtt trükkösebbek is előfordulnak talán.

Az osztályos és hasonló kérdéseket pedig jó elsőre alapvetően érteni szerintem, mert egy idegen kódra ránezve mire kibogarássza a dolgozó, hogy akkor ki kivel van az nem 5 perc.

A nyílt vs. zárt kérdéshez annyit tennék hozzá, hogy mindkét tábornak igaza van PHP és más scriptek esetén. Manapság egy normál oldal ellen nem a direkt "odaülők és addig töröm amíg nincs valami" típusú támadások vannak napirenden, hanem az ismert hibákra kihegyezett botokkal próbálkoznak, sokszor vaktában. Egy nyílt projekt hátránya, hogy a kódot átnézve olyan rejtetteb bugra is rá lehet találni, amit egyébként a mondjuk standard külső próbálkozásokkal nem vagy csak nagyon nehezen lehet megtalálni. Ha pedig tényleg körmönfont atléta direktben nekiáll egy oldalnak, akkor jó eséllyel fog találni valamit, ami nem is biztos hogy az oldal, hanem mondjuk az oldal és a webszerver adott beállításai vagy együttes sechole-ja miatt lesz járható. Szerveroldalon az első robotos csoportra lehet jobban felkészülni és a második csoport dolgát lehet megnehezíteni.

A nyílt kódoknál további probléma, hogy az oké, hogy a T. készítő feltesz egy X verziót, de utána általában 0 a karbantartás mert hát "jajjnemfizetik és úristen". Cserében egy idő után kissé ementáli sajt jellegű lesz az oldal, a T. megrendelő pedig néz nagy szemekkel, hogy hát telespammeltek, deface-eltek, googleblacklisten vagyok mert betoltak egy spammer site-ot volt, spamlistán vagyok mert include-oltak egy vicceset és hasonlók. Egy mondjuk zárt kódnál viszont nem lesznek közkézen forgó exploitok és a standard támadási kísérletek ellen jobban lehet védekezni (pl. mod_security az apache-ban).

a kódot átnézve olyan rejtetteb bugra is rá lehet találni, amit egyébként a mondjuk standard külső próbálkozásokkal nem vagy csak nagyon nehezen lehet megtalálni.

Igy van. Viszont ha ezeket megtalaljak, akkor ki is javithatjak, igy potencialisan biztonsagosabb lehet a javitott verzio.

a T. készítő feltesz egy X verziót, de utána általában 0 a karbantartás mert hát "jajjnemfizetik és úristen". Cserében egy idő után kissé ementáli sajt jellegű lesz az oldal

A 0 karbantartas az megallapodas kerdese, lehet ra termektamogatast is vallalni. De meg ha nem is igy van, akkor sem kell egy jol megcsinalt kodnak mast csinalnia, mint amit a megrendelo kert...

SPAMtelenul - POP3 spamszuro szolgaltatas

Köszönöm a sok segítséget! Tényleg eszméletlen jó közösség alakult itt ki és itt tényleg értenek az emberek a dolgokhoz, nem úgy mint a többi gagyi fórumon. Szóval csábít a saját CMS de tényleg annyira összetett, hogy több év lenne megtanulni és aztán egy rendes rendszert írni. Jelenleg a Joomlát használom, és nem tudom, hogy továbbra is ezt használjam-e, mert eléggé unom, hogy sok felesleges dolog van benne, de ami kellene alapból pl hozzászólások, fórum, letöltések ezt mind külön komponenssel kell leszedni és mire ezeket beszerzem addigra elég foltos az oldal, nem egységes. :S Vagy térjek át Drupalra, Typo3-ra vagy esetleg WordPressre. Typo3-ról semmit se tudok, nem is hallottam még róla. Mennyire jó rendszer ez? WordPress az nem csak blogoknak van? Mert igazából nem blogos weboldalam van. Drupallal nem igazán volt problémám, csak annyi, hogy templatét írni nem igazán tudtam rá írni. Ennyiben tudnátok segíteni, hogy melyiket kellene használni, miért jó stb stb...

Ne csak ránk hallgass, magadra is! :)
Telepíts fel a gépedre mondjuk XAMPP-ot, amely segítségével létrejön egy olyan környezet (beállított Apache+PHP+MySQL), amelyben a saját gépeden, mindenféle kockázat nélkül kipróbálhatod ezeket. És próbáld is ki, mert a mi véleményünk csak egy dolog, de te fogod használni, neked kell, hogy kézreálljon. Olvasd el a szükséges dokumentációkat, keresd meg a felhasználói csoportokat, hogy jobban és használhatóbban tudj kérdezni, és értsd a válaszokat is.
Szóval a javaslatom: próba! :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Teljesen igazad van, csak kiment a fejemből (pedig pp-nél többször is olvastam róla), illetve ha többet meg szeretne ismerni alaposabban (én még mindig ezt javaslom), akkor egy XAMPP-pal jobban jár.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Ha wordpress-ben gondolkozol, akkor jo hir, hogy nem csak bloggolni jo. Lattam olyan ceges oldalt, amely uzleti celokra is azt hasznalja. PR-hirekre is kivalo, egy nagy halom theme van hozza (imho tobb, mint a drupalhoz). Azt nezd meg, hogy a neked kello funkciokat tudja-e? Es egy nagy halom plugin a baratod, ha a core wp keves lenne.

SPAMtelenul - POP3 spamszuro szolgaltatas

A Wordpressben még mindig divat az, hogy ha meggebedsz sem tudsz bizonyos elemek HTML megjelenítésén változtatni a rendszer módosítása nélkül? (Markánsan: menü)

Nekem anno amikor néztem (2.5 környéke talán) az volt az érzésem, hogy egy totál ad-hoc, sokszor tervezés nélkül összegányolt valami.

A kategórialista HTMLjét hogy változtatod meg? Attól, hogy kalapács (pardon blogmotor) van a kezünkben ne nézzünk már mindent szögnek... blognak. Vannak olyan oldalak, nem is kevés, amiknél az ul-li páros nem megfelelő, mert bele kellene tenni egy "Nyitólap" linket az elejére pl.

Hiába lesz biztonságos 1-2-3 nap esetleg egy hét után, ha addigra a fél internetet végigzúzták.

Ez a fajta update még sokszor a saját oldalaknál sincs meg és sokszor a karbantartásba nem értik bele valahogy. Mivel openszorszra gondolok, ezért a kód hiába csinálja azt, amit kér a megrendelő, ha az előző végigzúzás teljesül.

Én ott a tesztelésre hívtam a figyelmet. Nem nekünk kell meggyőzni, hogy melyiket válassza, neki kell kitapasztalnia ezt. Ezért ajánlottam az XAMPP-ot, mint egy a saját gépen futó tesztkörnyezetet.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

ha addigra a fél internetet végigzúzták.

Elmeletileg valoban lehetseges.

kód hiába csinálja azt, amit kér a megrendelő

En ez alatt azt ertem, hogy semmilyen mas illegalis muveletre nem kenyszeritheto ra az app. Ebben az esetben pedig nincs "vegigzuzas".

SPAMtelenul - POP3 spamszuro szolgaltatas

Nem ez nem elmélet. :) A hosztolt Joomlás és Wordpress oldalak ellen rendszeres a próbálkozások hada és általában a mod_security vagy a php beállítások fogják meg a kis huncutokat nálunk.

Kevered a zárt dolgokat, a végigzúzás a nyílt kódos 0day exploitos csodákra vonatkozott.

Bocsánat, de nekem az szokta kiverni a biztosítékot, hogy vérprofi fejlesztők nem a saját munkájukat használják a saját referenciáik bemutatására.
Ez nem ellentmondásos?
Mert ha egy WP/Drupal jobban megfelel erre a célra, akkor meg szvsz szart sem ér a munkája, hiszen egy ilyen művelet kb a létező legegyszerűbb; nem is tudok olyan oldalt, ahol nem jelenítenének meg tartalmat.

Mindenki meg ugye nem tartozik a WP/Drupal Core team -hoz...

szürkehrteg
azenoldalamponthu

Ez olyan mint a suszter cipője. Egy website megalkotása mondjuk from scratch 100 munkaóra körül teendő. Lehet, hogy ennyit nem ér meg vagy nem tud ennyi időt nélkülözni. Főleg, aki mondjuk backend fejlesztő, annak a felületről baromira nem látszik semmi a tudásából.

Nekem pl a saját oldalam nincs karban tartva mióta. Saját fejlesztés, de nincs energiám rá írni. Az jobb?

de egyfizetős munkánál hogyan számol el az ember?
mondjuk, hogy egy biztonságos rendszert kérnek tőled, de a cms-ben, amit alapul veszel, találnak egy biztonsági rést, amit mások jól ki is fognak használni. A megrendelő ilyenkor rögtön téged fog felelősségre vonni, mivel őt csak az érdekli, hogy neked fizetett a melóért és nem mondhatod, hogy de hát nem te a hibád... ilyenkor mi helyzet?

szerk: Főleg akkor nem, ha ráadásul nem kevés pénzt fizetett neked a megrendelő

"ilyenkor mi helyzet?"
letöltöd a javítást, és felrakod. Aztán sűrűn bocsánatot kérsz, hogy nem frissíted a rendszert.

Apropó: ha egy saját cucc esetén hagysz egy szép kis SQL injection-t, aztán mondjuk a gonosz krekker törli a teljes adatbázist, és te nem csinálták backupot (mivel úgyis szuperbiztonságos a rendszered), akkor mit teszel?

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

De ha egy rést még azelőtt használnak ki, hogy megjelenne rá a javítás? Hiába magyarázod a megrendelőnek, hogy de hát ez nem a te hibád, ő felmegy a harmadikra és onnan fogja lesz@rni, hogy kinek a hibája, ő fizetett neked és ennyi. Innentől kezdve te vagy felelősségre vonva minden nemű adatvesztésért. Tapasztalatból mondom, mert mert volt már részem ilyenben. Meghülyült az adatbázis szerver és bizonyos adatbázisok nem voltak elérhetőek azon a szerveren, míg ugyanazok a fájlok másikon rendesen működtek és utána hallgathattam, hogy miért nem elérhetőek a cég kb. 2 éves adatai...
Én írtam a PHP alkalmazást, én raktam össze és telepítettem és tartom karban a kiszolgáló gépet és minden éjfélkor automatikusan készül back-up az adatbázisról SQL-be is, mégis beüthet valami geb@sz.

Miért? Ha elég sokat fizetnek? Egy webes rendszer nem egy olyan baromi bonyolult dolog, hogy ne lehetne hibamentesen megírni. A szerződésben meg nyilván az is szerepel, hogy mi van, ha van benne hiba. Kijavítod, fizetsz, etc. Ha fizetnek a hibamentes szóért eleget, akár megérheti. Ez ugyanolyan, mint a 99%-os rendelkezésre állás. Be kell bizonyítanod, hogy a kódban van a hiba. Ha nem tudod bizonyítani, csak jösz hogy "föltörték", az semmit nem jelent.

"Egy webes rendszer nem egy olyan baromi bonyolult dolog, hogy ne lehetne hibamentesen megírni."

Nem-e?
Egy "webes rendszer"-hez a phpkodon kivul sokminden tartozik, az adatbaziskezelotol az elotte figyelo load-balanceren at az alatta levo szerver procijaig.

"A szerződésben meg nyilván az is szerepel, hogy mi van, ha van benne hiba. Ha fizetnek a hibamentes szóért eleget, akár megérheti. Ez ugyanolyan, mint a 99%-os rendelkezésre állás."

Nyilvan, de ettol meg nem technikai, csak gazdasagi ertelemben lesz garantalhato.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Láttam is, írtam is. Ha néhány alapszabályra odafigyelsz, meg lehet írni jól. Az exploitok 99%-a ugyanis ebből a körből kerül ki. Szépen el kell választani a megfelelő részeket és akkor nincs probléma. Az alkalmazást egy ponton hívjuk meg (nem ahogy a Wordpress), a routing szabályok határozzák meg, mely controller mely actionje fut le, az adatbázisba bemenő adatokat escapeljük egy adatbázis absztrakción keresztül, ORMet használunk a model rétegben, amelyben benne van az adattípusok validálása is, kimenetnél a template rétegben escapeljük a kimenet formátumának megfelelően a változókat. Kihagytam valamit az alapokból?

Ha most olyasmit kezdesz feszegetni, hogy IWIW, az egy picit más, mint amiről itt a beszélgetés folyik. Ott egészen más kritériumok vannak. Én a téma szellemében beszéltem webes rendszerről.

Vezetni nem egy bonyolult dolog, ha nehany alapszabalyra odafigyelsz. Stabilan fogod a kormanyt, folyamatosan figyeled az utat es a visszapillanto tukroket, betartod a kozlekedesi szabalyokat es a mindenkori utviszonyoknak megfeleloen vezetsz, valamint minden indulas elott leellenorzod a fekeket, lampakat es gumikat.

vs.

Garantalom, hogy az en altalam vezetett autoban mindig biztonsagban utazol.

(off: a wiw, mint webes rendszer egy rossz vicc...)

A vezetésben a biztonság nagyon nagy részben függ a közlekedés többi résztvevőjétől is. Ők itt hol lennének a hasonlatban?

Off: sztem az IWIW mint webes rendszer nem feltétlenül rossz vicc, mert webes alapokon nyugszik, közösségi oldal és elég nagy ahhoz, hogy figyelembe lehessen venni. Milyen egyéb kritériumokat támasztanál egy webes rendszerrel kapcsolatban?

Meglepo modon a webes biztonsag is nagyban fugg a net tobbi resztvevojetol. A vezetos peldanal maradva sokan veled egyutt hasznaljak az utakat, nehanyan viszont le akarnak szoritani, beled akarnak menni, ellopni a parkolo autodat, stb...

Rovidre zarva: attol, hogy te kijelented, hogy hibamentes a kodod mert ilyen meg olyan(amugy helyes) elvek betartasaval irod meg nem lesz igaz ez a kijelentes, es senki nem is fogja ezt rajtad kivul elhinni neked.(aki meg elhiszi az is az elso x hibaig hiszi majd el)

Off-hoz: ha Karcsi es Tsa. Bt. weblapja annyit allna/karban tartasra szorulna, annyi xml errort dobna mint a wiw mar reg kirugtak volna az egesz IT reszleget. Tudom tudom az ertek amiert annyit fizettek anno a szemelyes adatokban van nem a szutyok javas kodbazisban, de akkor is...

Azért a témânál maradva, nehogy azt mondja nekem valaki, hogy egy blogmotort/stb nem lehet iskolapélda-szerűen jól összerakni. Nem atomrakétáról beszélünk, hanem kb 5-10, egyenként monjuk 5 interakciós lehetőséggel bíró komponensről. Lehet, hogy eleinte aránytalanul sok energia, de meg lehet normálisan írni.

Való igaz, de tökéletesen demonstrálja, hogy egy webes rendszer egy modulját meg lehet írni hibamentesen. Ha meg lehet írni egy részét hibamentesen, mi akadályozza meg az embert abban, hogy sok ilyen részt összerakjon egy jól működő rendszerré? Nyilván vannak olyan rendszerek, ahol már kinövi a feladat ezt a szintet, de az eredeti kérdés fényében nem erről beszélgetünk, mert az más, ahogy az IWIW is más.

Szerk: elkövettem azt a hibát, hogy az eredeti hozzászólásomban nem specifikáltam közelebbről, hogy az eredeti kérdés fényében óhajtottam szólni. Én hibám, sorry.

Valóban, ez esetben: GETre nem módosítunk adatot csak POSTra, a formokban pedig form token. Esetleg captcha a fontosabbaknál.

Egyébként van még millió egy dolog, amire oda kell figyelni, de az én tapasztalatom az, hogy ha a fejlesztés nem a "tegnapra legyen kész" elven működik, akkor csodálatosan jól összerakott dolgokat lehet alkotni.

csak épp a magyar webfejlesztőt-megbízunk mentalitás a mindenhez-értek-ezért-belepofázok és a áh-az-könnyű,-jövő-hétre-kész-legyen -ben testesül meg.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

"Valóban, ez esetben (...)"

"ha a fejlesztés nem a "tegnapra legyen kész" elven működik, akkor csodálatosan jól összerakott dolgokat lehet alkotni"

Nameg ha elotte valaki felsorolja az osszes hibadat. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Egy webes rendszer nem egy olyan baromi bonyolult dolog, hogy ne lehetne hibamentesen megírni.

Ahahahahhah, hibamentes hahahahahahah...

Annyi de annyi helyen lehet hiba hogy el se tudod kepzelni.
Vegyuk pl azokat a reszeket amiket nem te irtal (Most arra gondolsz hogy te ilyet nem hasznalsz, pedig de: vegyuk kapasbol a nyelv ertelmezojet amiben irod.)

Es igen, mocsok nehez dolog "hibamentes"-re megirni. Szerintem nem is letezhet ilyen.

Egy kozossegben fejlesztett rendszernek az a nagy elonye, hogy nem csak azok a hibak vannak kijavitva amik neked eszedbejutnak (itt ezt majd jol escapelem es nem lehet feltorni!), hanem amik masik x embernek eszebejutnak.
Hiaba gondolod hogy neked minden tamadasi felulet eszedbejut, nincs igy.

Maradjunk a kontextusban plíz. Lehet atomrakétában, load balancerben, nyelvi értelmezőben hibát keresni, de hogy szakszóval éljek, out of scope. Ergó tegyük fel, hogy az értelmező, a futtatókörnyezet hibamentes, mert ezek ellen rendszergazdai oldalon tudsz max védekezni, itt a fejlesztésről beszélünk.

Tehát keretrendszer, CMS, akármi. Beszéljünk konkrétumokról. Szépen szegmentálod a feladatokat, pl URL parzolás, adatbázis kapcsolat, output, HTML generálást, hogy csak néhány lényeges dolgot említsek. Ezekhez mindegyikhez elolvasod a megfelelő specifikációkat, hibalehetőségeket, RFC-ket stb. Hosszú folyamat? Kiba hosszú. Lesz benne hiba? Ha jól csináltad és a szegmensek határán jól ellenőriztél, legalább nehéz lesz kihasználni, ha van is benne gixer. Akkor is lesznek hibák, gyenge pontok, legrosszabb esetben maga a felhasználó lesz az a bizonyos láncszem vagy egy 20-30 megás vonalon úgy leDOSolnak, ahogy annak a rendje, de fejlesztői szemszögből legalábbis egy Joomlához, ne adj' Isten, Wordpresshez viszonyítva ég és föld a különbség.

Avagy magyarázza meg nekem valaki, hogy miért van az, hogy gyakorlatilag az összes nagy site (mindenki nézzen körül, biztos lát egy párat) egyike sem használ nyílt forráskódú motort? Miért van az, hogy a nagy szaktudású fejlesztőket _nagyon_ szépen megfizetik még kis hazánkban is, hogy ott egyedit alkossanak, ha a közösségi szoftverek annyira nagyon tutik? Szép és jó az open source hívőség, én is nagyon szívesen fejlesztek, javítok olyan dolgokat, amik utána szabad prédaként kikerülnek a netre, de amilyen forráskódokat néha... bocsánat, elég gyakran látok, mind nyílt, mind zárt forrású rendszerekben, az megingat abban a hitemben, hogy bármelyik is nyerő lenne. Legtöbbször olyan triviális hibák, trehányságok vannak bennük (komoly, nagy rendszerekben), hogy tényleg elgondolkozik az ember, hogy elkezdje megírni from scratch. Az egyetlen előnye az ilyeneknek, hogy voltak emberek, ha nem is feltétlenül a programozó-elittből, akik belefektették azt a sok száz/ezer munkaórát, hogy működőképessé tegyék a szoftverüket.

Szerk: ha már Drupalos vagy, és légyszi ne vedd személyeskedésnek, meg lehetne példának okáért javítani, hogy ha a telepítő nem találja meg a default.settings.php-t (mert mondjuk már át lett nevezve kézzel), akkor ne szarja össze magát hibaüzenet nélkül. Úgy érzem, hogy egy jól megtervezett szoftvernek egy fileművelet sikertelenségét le kellene kezelnie, nem?

Azert az "osszes nagy site" azert egy icipicit tulzas. Mondjuk ugy, hogy azon site-k, amik mogott van penz is, azok nagyreszt nem hasznalnak opensource cuccot; azonban a nagy free site-k (mert ilyenek is vannak) sokkal kisebb reszben hasznalnak belso cuccokat, altalaban valami opensource cucc az alap (ettol meg atfejleszthetik, de az alap nem sajat).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Van, amikor az alsóbb rétegek ismert hibáit az alkalmazásban kell megfelelő módszerekkel megkerülni/kivédeni, úgyhogy tetszik vagy sem, de nem lehet elvonatkoztatni attól, hogy a megírt kódot értelmező/végrehajtó réteg, vagy alatta az adatbázis milyen ismert, vagy feltételezhető hibákat tartalmaz.

Tegyuk fel hogy az ertelmezoben, webszerverben, kernelben, hardverben nincs hiba (hahahaha).

Akkor is fenntartom hogy te egyedul nem tudsz mindenre odafigyelni. Nem azert mert gyenge kepessegu vagy, ez ember feletti. Ezt tovabbra is fenntartom. Lehet hogy magambol indulok ki, de te tenyleg hibatlan kodot irsz? Elsore?

Ha mar drupalos vagyok, kiprobaltam hogy atneveztem a settings.php-t es bejott az install oldal (ahogy varhato volt), nem szarta ossze magat.
A kerdes a default.settings.php-re vonatkozott, bocs.

Szerintem ez abszolult nem edge case, elvegre 1x installalod, es miert nevezgetned at?
Masreszt ez le van irva az INSTALL.txt-ben hogy nem bantjuk, ha mar van motivaciod atolvasni a teljes(!) html-re vonatkozo rfc-t akkor ez szerintem nem tetel.

Azért feltételeztem ezt a valószínűtlen esetet, mert fejlesztőként nagyon ritka, hogy tudsz valamit tenni azért, hogy az alatta levő rendszer jobb vagy éppen biztonságosabb legyen. Ez rendszergazdai hatáskör, amibe bele lehetne vég nélkül menni. Nagyon jól tudom, hogy PHP kódból lehet segfaultoltatni az Apacsot és az xmlrpc extensionben akkora memoryleak van, hogy el lehet dönteni vele az egész szervert (20 perc erölködés után kill -9-el öltük meg a teszt során).

Ami az odafigyelést illeti, van egy olyan hátrányom hogy kib. lassan kódolok. Ha kapkodni kell, akkor hibázok. A számomra kényelmes tempó az kb az 1-2 osztály per nap, elolvasva az összes hozzá tartozó RFC-t, stb. (A legdurvább eddig az IMAP volt, attól én is kifeküdtem, a HTTP ahhoz képest egy könnyű esti novella. A legjobb HTML dokumentáció, amivel találkoztam a Stefan Münz SelfHTMLje, sajnos kizárólag német nyelven.) Nyilván, ez céges környezetben nem egy elfogadható tempó, mostanában szerencsére csak akkor kódolok PHP-t ha muszáj. Nyilván, hibákkal. Kapkodás, határidők, stb. napirenden vannak.

Ami a default.settings.php-t illeti, nem én követtem ezt el, hanem egy kolléga, aki az 5-ös Drupalos emlékei alapján próbálta telepíteni. Ez nem is lett volna baj, ha a telepítő legalább végső elkeseredésében kiköhögi a nyers hibaüzenetet. Ehelyett, ahogy az szokás, tolt egy redirectet, ami után már semmi nem látszott. A hibaüzenet csak akkor jött elő, amikor megkerestem a kódban a megfelelő részt és kikommenteztem. Én úgy gondolom, bár ez lehet, hogy az én egyéni baromságom, hogy egy PHP fejlesztő első dolgai kötött van egy saját hibakezelő implementálása az adott rendszerben (loggolóval karöltve), hogy az ilyen felettébb kínos eseményeket elkerülje. Az, hogy fájlműveleteket csinálunk mindenféle ellenörzés nélkül, már csak a hab a bizonyos torta tetején.

Nem mintha számítana, a Drupal az egyik legnormálisabb CMS rendszer, amivel valaha talákoztam, de ha a legnormálisabban ilyen számomra triviális hibák vannak, akkor milyen a többi? Persze, lehet, hogy én vagyok túl igényes (sznob) vagy túlságosan általánosítok.

Nyilvan tobb helyen is le van irva, hogy egy adott webalkalmazas telepitesenek mik a kornyezeti feltetelei (cache/upload irhatosaga, jogok, adatbazisban jogok). Ezek egy resze ellenorzesre kerul, mas resze pedig nem, mert a fejleszto joggal feltetelezi azt, hogy el tetszett olvasni az install guide-t.

A hibakezelo rendszer hianya viszont tenyleg fajo pont, es nem csak a drupal eseteben. A webalkalmazasok jo resze nem tartalmaz semmi ilyesmit, a PHP alatta meg igen kevesse konfigolhato, hogy akkor most merre, hogyan logoljon.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Pont hogy ne. A felhasznalora egyaltalan nem tartozik az, hogy az oldal eppen miert crashelt el, a hacker szamara pedig egyenesen kincsesbanya egy ilyen hibauzenet. Logoljon szepen egy szoveges fajlba, vagy eppen a syslog-ba, de a felhasznalohoz prod kornyezetben meg csak veletlen se keruljon at egy nativ PHP hibauzenet.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

a felhasznalohoz prod kornyezetben meg csak veletlen se keruljon at egy nativ PHP hibauzenet.

Egyetertek. De ne ugy, hogy eldugjuk, hanem mert mindent szepen lekezelunk, es ezert nem lesz hibauzenet a kepernyon. Ettol fuggetlenul akar loggolhatsz is ahova akarsz. Csak ne a php hibauzeneteit, mert azokat kezelni kell, es nem loggolni....

SPAMtelenul - POP3 spamszuro szolgaltatas

Minden biztonsági auditnak része egy olyan pont, hogy a felhasználó nem láthatja a rendszer hibaüzeneteit, hanem az alkalmazás ad _ellenőrzött_ hibaüzeneteket, amelyek lehetőleg minél kevesebb információt adnak a rendszer belső állapotáról.
Szintén a biztonsági audit része egy olyan másik pont, hogy megfelelő-e a naplófájlok kezelése.

Korrekt log készítése nagyon sokat segít a hibák megtalálásában, akár production környezetben. Nem beszélve a támadásokról, vagy akár csak a felhasználói hibákról.

Ezért futkározik az ember hátán a hideg, amikor pl. a vtiger telepítő konkrétan azt javasolja, hogy display_errors = On ÉS log_errors = Off

Üdv,
Gergely

Ui: PHP Runtime Configuration a következőt mondja display_errors -ról:

Note: This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).

+1. A felhasználó nem olvassa, és nem is érti a legtöbb esetben (sacc/kb. 90% fölötti arányban) a hibaüzenetet (még egy 404-es, de angol nyelvű hibaoldal értelmezésével is bajok vannak...), ergo haszna nulla, a fejlesztőhöz/adminhoz nem kerül vissza, és igen, auditon olyan szépen el lehet vele bukni -- bár szerintem mindenki ismer olyan, nagy nyilvános fórumot, ahol csak az nem találkozott a fórummotor által kiböffentett, elhasalt komplett sql-queryvel, aki nem járt még sohasem arrafelé... Na, ott pl. biztos, hogy senki sem foglalkozik a biztonsági kérdésekkel ilyen szinten...

A nagy site-ok közül egyre többen migrálnak Drupalra (biztos másra is, de én szakmából kifolyólag a Drupalt követem); érdemes Dries blogját olvasgatni a témakörben (ma pl Harvard váltott Drupalra, de nem rég volt a MIT is, New York szenátusa, rengeteg nagy és híres zenész oldala, Linux Foundation, a Nokia egyes oldalai, NHL, sourceforge.com, Now Public, slx.sun.com, flex.org, Novell egyes oldalai, Yahoo Research, MacWorld, Die Welt/The World, MTV UK stb). Nyílván vannak olyan site-ok, amik sohasem fognak (pl.: ahol van egy belső infrastruktúra, és ahhoz csak egy frontend). Ez van. De említhetném a speciálisan nagy forgalmú site-okat, mert ott is elég sokat kell már az infrastruktúrán reszelni, hogy a Drupal optimálisan fusson rajta (ezt meg már egyszer a saját motorjukkal eljátszották, hogy ráigazítottak egy szerverparkot), vagy csak túl sok az adat, és annyira más az oldal felépítése, hogy reménytelen lenne portolni. Esete válogatja. Általános esetben megéri nyílt forrású CMS-eket használni, még nagyobb cégeknek is.

Most kár, hogy nem mondhatok összehasonlítást, de amikor legutóbb ilyen jellegű próbálkozásaink voltak, akkor több szervert jelentett az a különbség, amit a saját fejlesztés hozott. Egyébként úgy érdekes lenne látni, már persze ha létezne ilyen statisztika, hogy mondjuk az Alexa TopX-ben hány F/OSS motort használó site van. Tényéleg kiváncsi lennék, hogy masszív rendszergazdai erölködés nélkül tudnak-e ezek olyan szépen futni, mint a custom built társai.

Ami a hibakezelést illeti, csak egy egyszerű if feltételre vágytam volna, ha már fileműveletet csinálunk. Ha nem sikerül, írjuk ki, hogy hülye vagy fiam. Általános hibakezelő már a non plus ultra lett volna. Egy triviális dologról van szó, amit programozó-tanfolyamoktól az egyetemekig mindenhol mantraként használnak, hogy le kell kezelni a hibás eseteket. Aki ilyet elkövet, azt nem nevezném jó fejlesztőnek és ezzel jól jellemzi, hogy a Drupalnak (kevésbé ugyan, mint a társainak) egészen kiváló kódrészek mellett vannak nagyon gyatra kódrészei is. A QA kicsit hiányzik, mert ha lenne, akkor valószínűleg ezt a kódrészt az első pillanatban dobta volna vissza.

Az F/OSS CMS-ek egyre népszerűbbek. Nem csak azt kell nézni, hogy most hogy állnak, hanem azt is, hogy milyen ütemben terjednek.

Masszívabb rendszergazdai erőlködés nélkül sehogyan sem, ahogy a custom built cuccok sem. Ott is kiépítettek egy infrastruktúrát, amivel összecsiszolgatták a rendszert. Nem lenne fair, ha egy X rendszer számára optimalizált környezetbe beledobod Y rendszert, aztán csodálkozol, hogy lassú.

Miért kellene követelménynek lennie, hogy ha $RANDOM fájlt törölsz, akkor működőképes maradjon a rendszer? Normál esetben nem törlünk semmit.

Miért kellene követelménynek lennie, hogy ha $RANDOM fájlt törölsz, akkor működőképes maradjon a rendszer? Normál esetben nem törlünk semmit.

Nagyon igaz, ennyi erovel torolhetnel egy random .inc fajlt is, es csodalkozhatnal hogy miert nincs lekezelve, csak undefined function errorokat kapsz.

Persze. Elvileg az összes hiba lekezelhető. DE... Minden hibakezelő rutinnak időre/erőforrásra van szüksége a lefutásához. Ha egy komponens létét futásidőben, minden alkalommal, amikor hivatkozás van rá ellenőrizni akarod, akkor ez igen jelentős plusz terhelést fog jelenteni, ugyanakkor viszont egy normálisan telepített rendszerben a működés biztonságát nagyjából bolhapuki mértékben fogja növelni.

Ne vicceljünk már, hogy néhány if akkora terhelést rakna a szerverre, hogy ne bírja el. Lehet, hogy 10 éve így volt, de effelől is kétségeim vannak. Ma már vannak szép kis opcode cachek, arról nem beszélve, hogy kultúréknál az egész rendszermagot összecummantják egyetlen fájlba. Ez nem biztonsági kérdés, hanem debuggolhatóságot rontja ha valami nem működik. Elbasztam egy tök triviális probléma megkeresésé vel kb egy fél órát. (Nem, nem volt debugger, a rendszer élesben ment.)

Nem devel környezetben hol érdekel, hogy mennyire ronda a kód? Az elmúlt néhány évben nagy terhelésű siteoknál ugyanezt szokták volt csinálni a CSS és JS fájlokkal. Azon nem láttam fönnakadni hosszabb ideig senkit, akkor a PHPnél miért probléma? Az includeos kérdést meg nem értem, lehet autoloadot használni és akkor nincs belőle probléma. Meg persze lehet azon lovagolni, hogy PHPben nem lehet rendes OOPs kódot írni és helyette szanaszét includeolni a kódot és csodálkozni, hogy nehéz hibát kezelni.

A CSS és a JS aggregáció azért jó, mert csökkenti a hálózati terhelést (értsd: optimális esetben 2-2 HEAD/GET kérés sok helyett), viszont PHP fájloknál ez abszolút értelmetlen, mert:
1.) az a pár kb PHP fájl úgyis végig a file cache-ben csücsül
2.) van opcode cache
3.) más oldalletöltésnél akár teljesen más fájlok include-olódnak; erre elég sok rendszer épít is (a Drupal pont kevésbé); ennek a kijátszására trükközés kell -> automatizálás kizárva -> kézi összepakoláskor további bugok lehetnek

Az egésszel csak annyit akartam mondani, hogy az include-ok szervezése ne legyen már indok arra, hogy nem ellenőrzünk hibát. Ennyi. Ha valakinek problémája van a sok include-al, akkor másolja össze őket. Normálisan megírt rendszernek tök mindegy, hányfele vannak szétbontva a fájljai. De igazából kezd teljesen irreleváns lenni a vita, mert olyan dolgok jönnek itt elő, amit magára valamit adó fejlesztő nem ír le. Azért nem kezelünk hibát, mert overhead? WTF? Nem akartam személyeskedni, de ez innentől kezdve mindenféle mérnöki szemléletet nélkülöz.

Tudom, hogy az a gond a Drupallal, hogy nincs minden sor előtt egy 10 képernyő széles if, de ez van. Amíg PHP-ban nincs rendesen a kivételkezelés támogatva, addig nem lehet hatékonyan mindenre kiterjedő hibakezelést impelementálni a kód áttekinthetőségének drasztikus romlása nélkül. Tudom, de át tudnád látni, de nem mindenkinek van kedve 30 függvényre visszanyúló else ágakban bogarászni.

Jah, és emellett legyen olyan gyors, mint pistike 200 soros blogmotorja. Értem én. Tessék menni az issue queue-ba, és bejelenteni az igényeidet. Nyitva a Drupal 7 merge window-ja, most pont a feature request-ek idején tart a fejlesztés.

Ne haragudj, foreach ($includefile as $file) {}, erről már hallottunk? Vagy autoloadról? Ne komolytalankodjunk már, meg lehet normálisan szervezni. Az, hogy a Drupalosok ragaszkodnak ahhoz, hogy a PHPban nem lehet normálisan hibát kezelni, a sok követője meg ész nélkül hajtogatja utánuk, az nem jelenti azt, hogy úgy is van. Van benne exception, lehet osztályokat írni, lehet autoloadot használni, 5.3-tól kezdve lesz late static binding is, csak a Drupalos uraknak ez túl előkelő. Láttam már olyan rendszert, ahol szépen meg volt csinálva a hibakezelés, a kód tervezési minták ismeretében első olvasatra átlátható volt és performanciában semmivel nem maradt el sem a Drupaltól, sem a haverjaitól, sőt sebességben inkább 2-3x rávert kb napi több tízezer unique látogatónál.

Nekem nicsenek ilyen igényeim a Drupallal szemben (tekintve, hogy nem használom), mint ahogy elnézem, a Drupal közösség többségének sem. Csak bosszantott az open source mérnökileg az egekbe magasztalása, amikor ilyen kódminőségbeli problémák vannak a zászlóshajóval. Részemről a téma lezárva, ha tetszik, vegyétek úgy, hogy nyertetek. Nem kell hibakezelést programozni, jó az úgy, ahogy van. De ez akkor sem minőség.

6-osig támogatott a PHP 4, ott nincs ilyesmi (persze, 5.3, talán majd 5-6 év múlva lehet ráépíteni). A 7-esben dobják a PHP 4 támogatást, ott nem tudom, hogy mennyire vannak elől az exceptionokkal, de arra nincs erőforrás, hogy egy-az-egyben paradigmát váltsanak a rendszer alatt (ez nem KDE).

Ém is így látom. A php5-ben már igen szép, karbantartható kódokat lehet csinálni, elég a Zend Framework kódjába belenézni.

Nyilván a drupál féle megközelítés is működik, de ahányszor belenézek, a hideg kiráz...

Szerintem nem fogják tudni a 7-esben lecserélni ezt az architecturát alatta, de még nem néztem meg a drupal7 kódokat.

Ha oop lesz a drupál, akkor a fejlesztő pistikék 90%-a egyből kiesik -> a rendszer jobb lesz :D
--
http://internode.hu

Igen, csekkoljuk, megelőzendő azt, hogy a rendszer bizonyos részei hiányoznak. Egyrészt a felhasználó kapjon hibaoldalt, ha valami nem frankó (főleg azon fájlok esetén, amikhez a felhasználó potenciálisan hozzányúl) másrészt fejleszteni is könnyebb lenne, ha egy logban megjelennének normális hibaüzenetek.

A PHP4-et suppportálni akaró emberektől meg kérdem (külön hozzászólás se ér meg) hogy nem a Drupal volt a GoPHP5 egyik legnagyobb hangoztatója?

De ők voltak, viszont legtöbbször a szoftvernek kell igazodnia az őt kiszolgáló környezethez, és nem fordítva. Találkoztam nemrég olyan kis "szolgáltatóval", amelyik még mindig csak PHP 4-et adott.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Mi az, hogy a rendszer valamely része hiányzik? Az include-oláson ne szálljon el, ha elszáll, akkor az adjon korrekt hibaoldalt -- ezt oldja meg a kód értelmezését végző motor, ne neked kelljen csekkolni. Egy shellscriptben sem kezded úgy, hogy az összes, használni kívánt binárisra futtatsz egy ldd-t, és ha valamelyikhez nincs meg az összes lib, akkor hibakezelésre ugrik... Pedig dettó erről van szó...

Szerintem max akkor lehet ronda a kód, ha magadnak taknyolsz valamit (hirtelen le kell válogatnod egy listát, amit majd importálsz valahova).

Ha eladásra megy a kód, vagy többen fejlesztetek, akkor nem lehet se ronda, se érthetetlen. A dokumentáció sem hiányozhat.

Rengetegszer van, hogy régi kódomba kell turkálni, javítani. Nekem jó, ha ránézek és eltalálok a kódban egyszerűen és a kommentek segítik felderíteni, hogy mit és miért csináltam.

Sokszorosan megéri szép, dokumentált kódot csinálni.

--
http://internode.hu

Ha többen fejlesztik, akkor természetes, hogy crosscheck miatt egységesen (és olvashatóan) kell kódolni (mert ugye egynél több kóder esetén egymás munkájának átnézése is része a fejlesztésnek!) -- ami production-be megy, az normális esetben marad ugyanaz, ami a fejlesztőtől jött, az obfuscated source nagyon randa, és értelmes megrendelő által nem tolerált móka.

Mar megbocsass, de ebben az egyben nincs igazad. Egy rendszer igenis ismerje magat annyira, hogy ami a futasahoz kell, azt meg csak veletlen se engedje torolni. Ezt becsulom a Windows-ba is, ott meg az admin ellen is vedekezik a rendszer, ha a system konyvtarakban turkalsz. Azert linuxon siman le lehet torolni a ld-linux.so-t...
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mondta valaki egy szóval is, hogy működőképesnek kell maradnia? Nem. Ellenben az, hogy úgy tesz, hogy működőképes, hibaüzenetet nem ad, de közben rohadtul nem működik, szerintem nem elfogadható.

Megoldási javaslat:

- index.php-ba teszel egy kibaNagyHibaVan() című függvényt, ami az API részét képezi és kidob egy HTTP 500-as hibát, illetve valami értelmes módon loggol (panic.log pl) majd exittel kilép.
- A bootstrap folyamatban ellenörzöd ennek a meglétét, különben HTTP 500 és exit.
- Mindig, amikor betöltesz egy komponenst, ellenörzöd, hogy tényleg megvan-e, különben eloopsolsz.

Ez nagyon szépen működik, kivéve persze a syntax errort, de azt meg PHPból nem tudod lekezelni.

Avagy magyarázza meg nekem valaki, hogy miért van az, hogy gyakorlatilag az összes nagy site (mindenki nézzen körül, biztos lát egy párat) egyike sem használ nyílt forráskódú motort?

http://buytaert.net/tag/drupal-sites

És biztos lehetne hasonló linkeket adni más nyílt forráskódú tartalomkezelő rendszerekhez is.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."


Szerk: ha már Drupalos vagy, és légyszi ne vedd személyeskedésnek, meg lehetne példának okáért javítani, hogy ha a telepítő nem találja meg a default.settings.php-t (mert mondjuk már át lett nevezve kézzel), akkor ne szarja össze magát hibaüzenet nélkül. Úgy érzem, hogy egy jól megtervezett szoftvernek egy fileművelet sikertelenségét le kellene kezelnie, nem?

  • Drupal 5-ben nincs default.settings.php. Az a 6-ban van.
  • Az általad felrótt hiba csak a régebbi 5-s drupalon jelentkezett és wines apache-on. Vajon miért is?
  • 5-6 egyarán ordít ha nem talál valamit. Vicces, hogy pont a "drupal" hibajelentésébe kötsz bele.

No rainbow, no sugar

Ez igaz, de egy post beküldése (ezáltal a működés prezentálása) ott sem bonyolult user oldalról.
Te magadnak pl. miből csinálnál oldalt?
Drupal/WP/muPortal?
Tehát arra akartam rávilágítani, hogy ha én csináltam valamit, akkor azzal mutatom be magam, nem idegen tollakkal ékeskesdek. Neked is valószínüleg volt pl. a muPortal -on alapuló megrendelésed.
Egyébként nekem nagyon bejött az a cucc; gyakorlatilag a fejlesztési modelled miatt.

szürkehrteg
azenoldalamponthu

( Proci85 v | 2009. 05. 23., szo – 15:36 )

e107-ben meg lehet oldani, hogy ha a fenti menüben rákattintok egy linkre, bejön egy aloldal és _ezen_ aloldal jobb oldalán menü linkek jelennek meg? Viszont ezek máskor ne jelenjenek meg.
Pl. fent viccek menüpontra bejön egy akármilyen oldal és a jobb oldalon vicc 1, vicc 2 linkek. Bármelyik viccet olvassa az ember, jobb oldalon az _adott_témához kapcsolódo menü linkek lesznek.

Tudom, ezeket nekem kell felvenni és beállitani, de megoldható?
A napokban nézegettem több CMS-t is, Drupalnál találtam olyat, hogy adott menü linket le lehet tiltani, és csak adott oldalnál engedélyezni a megjelenését.
Az e107 is tud ilyet? Kis website-os igényeimet kielégiti, viszont ezt az egyet nem találtam meg egyelőre.

( Gergely | 2009. 05. 24., v – 10:53 )

make code not war! :)
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.

( pgabor v | 2009. 05. 25., h – 10:09 )

Az ingyenes CMS rendszerek egyik fontos előnye, hogy tapasztalt programozók írják/írták, akik bőven túl vannak az alap kérdéseken. Viszont egy óriási buktató, hogy bárki belenézhet a forráskódba és ezért nagyon könnyű új biztonsági rést találni. Ha tisztában leszel az alapvetőbb biztonsági kérdésekkel, szvsz jobban jársz egy saját CMSel, mint egy nyílt forráskódúval. Továbbá azt javasolom, tegyél fel több ingyenes CMS-t, hasonlítsd össze őket és ezek után tervezz sajátot.

Ami jó, ha van: ubuntu, svn, apache, php, phpdocumentor, mysql, phpmyadmin, smarty, adodb, backup-manager
Ami jól jöhet: link

Goto 10: nem, ismétlem nem a forráskód ismerete alapján buknak el elsődlegesen a webes alkalmazások, hanem a trehány megvalósítás látható, illetve blackbox tesztekkel is kideríthető hibáinak a kihasználásával. Az, hogy elérhető a forráskód, az maximum olvasnivalót jelent arra az időre, amíg az automatizált tesztek futnak.

Igen, csakhogy a biztonsagi hiba kereses az nem egy feloras melo, ha csak a forraskod alapjan mesz. Valoszinu, hogy mire talalsz egy hibat a kodnak abban az allapotaban, amit nezel, az mar a fejlesztok altal javitva van, es eppen kiadasra var. A blackbox tesztek sokkal gyorsabban talalnak hibat.

Arrol nem beszelve, hogy attol, mert a _kiadott_ forras hibas, attol meg nem biztos, hogy az altalad latott oldal is tartalmazza ezt a hibat, hiszen a nyilt forraskod okan akar az uzemeltetok is kiszurhattak a problemat, es javitottak, amig a hiba hivatalos javitasa ki nem adattatik. Persze probalkozni lehet, de szerintem sem erdemes.

Arrol nem beszelve, hogy ha mar az ember forraskodot bujik egy oldal feltoreseert, akkor annak az oldalnak nagyon meg kell ernie a munkat, mert egy sima forum/blog feltoresehez egyszeruen pazarlas ennyi idot szanni. Mindjart mas a helyzet, ha a MNB vagy valami mas bank oldalarol van szo.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"mire talalsz egy hibat a kodnak abban az allapotaban, amit nezel, az mar a fejlesztok altal javitva van"

Ezt inkább azoknak a joomla tulajdonosoknak írd, akiknek ott vigyorog a török zászló a címlapjukon :)

upd: a mnb oldalát drupalban vagy esetleg phpnukeban írták? - kíváncsi vagyok, nem tudom.

Azt senki sem mondta, hogy ha valami open source, akkor az ok-okozat alapjan tuti biztonsagos. A bugtraq-en eleg hosszu idore visszakovetheto, hogy pl. a phpnuke-ban mennyi sec. hiba van/volt. A joomla deface-ek kapcsan meg csak annyit, hogy hiaba van valami javitva (nem tudom, hogy igy van-e, latatlanban feltetelezem), ha a tarteruleten nincs frissitve (ezt is csak latatlanban).

SPAMtelenul - POP3 spamszuro szolgaltatas

Ez igaz, de ha csak a patchet alkalmaztak az oldalra, es nem raktak fel az uj verziot (barmilyen okbol kifolyolag) akkor csak forraskodelemzessel a budos eletbe nem hasznalod ki azt az exploitot. Ezert elsodleges a blackbox elemzes, a forraskod csak akkor jon kepbe, ha az oldal toresehez onnan van szukseg infokra; azonban ez a legritkabb esetben fordul elo.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

egy óriási buktató, hogy bárki belenézhet a forráskódba és ezért nagyon könnyű új biztonsági rést találni.

vagy mar annyian beleneztek, hogy regen kijavitottak a biztonsagi rest. A sajat cms akkor jo alternativa a (mar elerheto) nyilt forrasuakkal, ha

- legalabb olyan jo vagy, mint ok ES
- van idod ujra feltalalni a langyos vizet, es nullarol megirni azt, amibol vagy 200 fajta mar letezik ES
- olyan funkcio kell, amit azok nem tudnak, es nem akarsz beszallni egyikhez sem kontributorkent

Ha ezek legalabb egyike nem teljesul, akkor joesellyel bukni fogsz vele

SPAMtelenul - POP3 spamszuro szolgaltatas

"Kár, hogy nincs értelmes alternatívája."

Most nem fejlesztésről van szó? Ott ne bohóckodjunk már php(my|pg|lofasz)admin-okkal... Ott a MySQL GUI tools, ott a PgAdmin III, ott egy csomó másik jó 3rd party tool az adatbázis matatásához (SQL Maestro-s cuccok nekem pl. bejönnek, kár, hogy fizetősek, igaz nem drágák).

----------------
Lvl86 Troll

Igen, csakhogy a GUI-s cuccokhoz engedely kell, hogy a szervertol eltero hostrol is csatlakozni lehessen az adatbazishoz. Ezt a legtobb helyen egyreszt nem kedvelik, masreszt, ha engedve is van, csak es kizarolag a webszerverek szamara. Nagyon sok kort kell szaladni azert, hogy _barhol_ engedjenek neked egy direkt kapcsolatot a db szerverrel.

A webes cuccok ezt oldjak fel, hiszen ok ott futnak, ahol egyebkent majd az app is fog futni, tehat pont ugyanazokkal a hostszintu jogokkal indul neki.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Milyen szerver? Fejlesztésről van szó. Helyi géphez, maximum irodában lévő teszt szerver szerintem nem képezi azoknak a gépeknek a halmazát, amihez 26 belépőkártya és 50 tűzfal kell.

"Nagyon sok kort kell szaladni azert, hogy _barhol_ engedjenek neked egy direkt kapcsolatot a db szerverrel"

Nem mindig. És miért kellene bárhova? Elég az irodához/otthonra, csak egy FIX IP kell hozzá.

Egyébként egy public-ban hagyott phpmyadmin se sokkal securebb, szvsz.

----------------
Lvl86 Troll

( rozmar564 | 2009. 05. 26., k – 16:39 )

Valaki errol hallott/olvasott/hasznalta http://plone.org/ ? Mi most fogunk erre atalni - kb. 150 site fog futni... ha minden igaz.