Door
Ozzie PHP
op 30-12-2010 16:10
gewijzigd op 06-01-2011 13:17
50.696 views
Hmmm, laat ik de vraag toch maar eens stellen. Ik wil graag een eigen framework / beheersysteem maken. De bedoeling is dat ik als het systeem klaar is heel makkelijk een website kan maken waar meteen al een standaard cms gedeelte in zit.
Ik ben al begonnen met een framework en ik maak daarbij gebruik van Zend Framework, maar nu vraag ik me het volgende af. Ik heb behoorlijk wat PHP kennis en ervaring inmiddels, maar ik heb hier geen opleiding voor gehad. Ik wil het mezelf dan ook altijd zo makkelijk mogelijk maken als ik aan het programmeren ben. Voorbeeld, als ik een databasequery wil uitvoeren dan wil ik niet een hele query in te hoeven typen, maar wil ik simpele functies kunnen gebruiken, bijvoorbeeld: $database->setTable('tabel') en $row = $database->select('naam') etc.
Ook vind ik het handig dat ik in Zend Framework een route makkelijk kan koppelen aan een controller en een actie. Daarnaast gebruik ik de MVC structuur (modules), de Zend_Registry functie om iets op te slaan en gebruik ik de caching functie voor het cachen van gegevens.
Ik gebruik Zend Framework dus voornamelijk voor:
- maken van mooie routes
- routes koppelen aan controller en actie
- MVC structuur (modules)
- Zend_Registry om variabelen op te slaan
- Caching
Voor de rest gebruik in Zend Framework eigenlijk niet. Ik weet dat er heeeel veel mogelijkheden in Zend Framework zitten, maar ik ben niet iemand die dat allemaal wil uitvogelen, en ik wil toch altijd graag mijn eigen code schrijven zodat ik precies weet wat de code doet en hoe deze in elkaar zit (zodat het voor mijzelf logisch is en makkelijk te gebruiken).
Nu vraag ik me 2 dingen af:
1) is het voor mij eigenlijk wel zinvol om Zend Framework te gebruiken aagezien ik er niet heel veel mogelijkheden van benut.
2) zijn de 5 functies waar ik gebruik van maak (makkelijk) ook zelf te maken of is dat heel erg ingewikkeld?
Wat raden jullie aan? Zend Framework blijven gebruiken ook al gebruik ik er maar weinig van? Of toch zelf mijn eigen functies maken en Zend Framework niet meer gebruiken? Ik stel deze vraag ook omdat Zend Framework zo'n 23mb aan serverruimte in beslag neemt.
Ik ben nog nooit tegengekomen dat je door middel van http://www.example.com/.htaccess de .htaccess in kon zien. Wat dat betreft is het overbodig.
Dit staat in (denk ik) elke httpd.conf
#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<FilesMatch "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
Wat een hoop feedback weer :)
Sorry dat ik een hoop vragen stel, maar ben in htaccess totaal niet thuis, maar vind dat ik al best een eindje gekomen ben :)
Mark PHP op 06/01/2011 12:08:37
[quote="Ozzie PHP op 06/01/2011 11:53:35"]
Ik dacht ergens te lezen dat die All voor alle onderliggende directories geldt ofzo... maar weghalen dan maar?
Klik. Het kan niet heel veel kwaad als je All laat staan, persoonlijk gebruik ik het nooit.
[color="red"]- Oke dan laat ik m staan.[/color]
Ozzie PHP op 06/01/2011 11:53:35
Oke, maar ook htaccess wordt hierdoor beveiligd. Kan het kwaad om 'm te laten staan? Mocht er toch ooit per ongeluk een kritisch bestand in komen te staan?
Ik ben nog nooit tegengekomen dat je door middel van http://www.example.com/.htaccess de .htaccess in kon zien. Wat dat betreft is het overbodig.
[color="red"]- Klopt, in principe moet een goede server configuratie dit voorkomen, maar als je een lekke server hebt... Baadt het niet dan schaadt het niet zou ik zeggen?[/color]
Ozzie PHP op 06/01/2011 11:53:35
Oke, maar stel nu dat op een server de rewrite engine niet werkt, dan is dit toch een extra beveiliging? (als ik overigens de rewrite rules weghaal kan ik nog gewoon webbestanden aanroepen, dus dat hele FILES lijkt niks te doen. Of doe ik iets verkeerd?)
Dan werkt je hele framework toch niet meer. Bovendien heb je nog steeds geen beschermde bestanden in de webroot staan, dus overbodig blijft het.
Wat bedoel je precies? Media bestanden gaan nu toch sowieso niet via het framework?
Normaal gesproken (als een media bestand bestaat) niet. Maar stel nu dat je linkt naar een niet bestaand plaatje (bv. images/logo.jpg). De RewriteCond is dan waar, dus wordt je plaatje geroute naar http://www.example.com/index.php?route=images/logo.jpg. Oftewel via je framework. Dit is zonde van je performance, je kan dan beter meteen via .htaccess een 404 terug geven. (Ik zou overigens ook in m'n framework kunnen kijken of de request een extensie bevat en zo ja dan direct een 404 tonen. Is dat wat? Wat gebeurt er eigenlijk als je een plaatje wat niet gevonden wordt een 404 teruggeeft of door je framework gooit? Geeft dat problemen in de img src?)
[color="red"]- Da's inderdaad een hele goede van je. Heb alleen geen idee hoe ik dit in m'n htaccess krijg? Moet ik dan alle verschillende mediatypen toevoegen? Of kan ik ook een of andere algemene 404 rule maken? Graag je hulp met deze.[/color]
Ozzie PHP op 06/01/2011 11:53:35
Ik dacht dat die Limit geldt voor aanroepen die niet via de browser worden gedaan (maar bijvoorbeeld via dos prompt / server) en dat dit voorkomt dat iemand via niet-browser aanroepen dingen doet die niet mogen. Maar zou goed kunnen dat hier helemaal niks van klopt wat ik nu zeg :)
Klik. Dit klopt inderdaad niet :-) Wil je methoden blokken, dit werkt:
# Allow GET, HEAD and POST
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
RewriteRule .* - [F]
Let er wel op dat dit een 403 (Forbidden) teruggeeft. Dit zou eigenlijk een 405 moeten zijn, maar dan ben je verplicht om een Allow header mee te sturen. Bovenstaande is dus eigenlijk een quick-and-dirty fix.
[color="red"]-Oke, die limit eruit gooien dus en bovenstaande toevoegen? Waar ben ik dan tegen beveiligd eigenlijk?
Stel dat de rewrite engine niet werkt, ben ik dan uberhaupt nog wel beveiligd?[/color]
Da's inderdaad een hele goede van je. Heb alleen geen idee hoe ik dit in m'n htaccess krijg? Moet ik dan alle verschillende mediatypen toevoegen? Of kan ik ook een of andere algemene 404 rule maken? Graag je hulp met deze.
Dit regelt afbeeldingen, styles en scripts. Andere extensies kan je gewoon toevoegen.
# Handle media
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.(css|gif|jpe?g|js|png)$ - [L,R=404]
Om het nog mooier te maken zou je natuurlijk afbeeldingen kunnen redirecten naar een blanco afbeelding met de tekst "Afbeelding niet gevonden". Hier zitten wel haken en ogen aan, aangezien niet elke afbeelding hetzelfde formaat heeft.
Ozzie PHP op 06/01/2011 12:26:52
Oke, die limit eruit gooien dus en bovenstaande toevoegen? Waar ben ik dan tegen beveiligd eigenlijk?
Stel dat de rewrite engine niet werkt, ben ik dan uberhaupt nog wel beveiligd?
Dit heeft niets met beveiliging te maken, meer met wat je applicatie support. Simpele websites werken eigenlijk alleen maar met GET, HEAD en POST. De rest zou je dan kunnen blokken. Mocht iemand dan toch een DELETE request willen doen, krijgt deze netjes de melding Method Not Allowed.
Als je naar wat meer ingewikkeldere applicaties gaat kijken, dan is het soms heel wenselijk om ook DELETE, PUT, OPTIONS en dergelijke te ondersteunen. Goed voorbeeld zijn RESTful web services.
"Die <Files> heb je daar helemaal niet voor nodig." Nee, die heb je niet nodig om het framework te laten werken. Dat klopt. Ik wilde het echter gebruiken als beveiliging voor als de rewrite engine niet werkt. Alleen als ik dus (om te testen) de rewrite rules weghaal en dat blokje FILES laat staan, dan kan ik toch een html bestand aanroepen. Heb jij een idee hoe dat kan? Ik was in de veronderstelling dat ik dan een 403 zou krijgen namelijk.
Hmmm... dat rewrite rule regeltje van die images vind ik wel irritant want dat geldt natuurlijk voor alle document types en dat zijn er een stuk of 40. Wat gebeurt er als ik een niet gevonden plaatje toch door het framework stuur? Kan ik dan via het framework een "niet gevonden" pagina aanroepen?
Tot nu toe heb ik dan dus dit... klopt er nu nog iets van? :-s
Options All -Indexes
AddDefaultCharset utf-8
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
RewriteRule .* - [F]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} .(inc|ini|p?ht.*|php.*|txt)$
RewriteRule ^(.*)$ index.php?route=$1 [QSA,NC,L]
</IfModule>
<IfModule mod_dir.c>
DirectoryIndex index.php index.html index.htm
</IfModule>
<Files ~ "\.(inc|ini|p?ht.*|php.*|txt)$">
order allow,deny
deny from all
</Files>
Nee, die heb je niet nodig om het framework te laten werken. Dat klopt. Ik wilde het echter gebruiken als beveiliging voor als de rewrite engine niet werkt. Alleen als ik dus (om te testen) de rewrite rules weghaal en dat blokje FILES laat staan, dan kan ik toch een html bestand aanroepen. Heb jij een idee hoe dat kan? Ik was in de veronderstelling dat ik dan een 403 zou krijgen namelijk.
Nogmaals, je hebt geen .html bestanden in je webroot staan, dus is die FILES niet nodig!
Ozzie PHP op 06/01/2011 13:34:46
Hmmm... dat rewrite rule regeltje van die images vind ik wel irritant want dat geldt natuurlijk voor alle document types en dat zijn er een stuk of 40. Wat gebeurt er als ik een niet gevonden plaatje toch door het framework stuur? Kan ik dan via het framework een "niet gevonden" pagina aanroepen?
Klopt, maar dat kost je performance. De meest gebruikte media types gaan via .htaccess, als iemand <iets>.<langerareextensie> aanroept gaat het via het framework. Daar ontkom je niet aan.
Ozzie PHP op 06/01/2011 13:34:46
Tot nu toe heb ik dan dus dit... klopt er nu nog iets van? :-s
Mijn voorstel (P.S. denk om inspringen, commentaar):
# Options
Options All -Indexes
# Configuration
AddDefaultCharset utf-8
# Rewriting
<IfModule mod_rewrite.c>
RewriteEngine On
# Allow GET, HEAD and POST
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
RewriteRule .* - [F]
# Forward to front controller
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?route=$1 [QSA,L]
</IfModule>
Merk op dat ik ook <IfModule mod_dir.c> heb weggehaald, dit is nutteloos aangezien je -Indexes gebruikt, en standaard al naar index.php wordt gezocht (naar ik aanneem). Voor meer tips zie deze site (NB je browser kan tijdelijk vastlopen alert).
[quote="Ozzie PHP op 06/01/2011 13:34:46"]
Nee, die heb je niet nodig om het framework te laten werken. Dat klopt. Ik wilde het echter gebruiken als beveiliging voor als de rewrite engine niet werkt. Alleen als ik dus (om te testen) de rewrite rules weghaal en dat blokje FILES laat staan, dan kan ik toch een html bestand aanroepen. Heb jij een idee hoe dat kan? Ik was in de veronderstelling dat ik dan een 403 zou krijgen namelijk.
Nogmaals, je hebt geen .html bestanden in je webroot staan, dus is die FILES niet nodig!
[color="red"]- Oke, maar stel ik wil bijvoorbeeld een "framework niet gevonden" pagina in de root zetten... dat zou wel kunnen. En ik wil niet dat mensen dit bestand kunnen aanroepen. Maar even er vanuit gaande dat ik die optie erin wil laten, hoe doe ik dit dan... want het werkt niet :([/color]
Ozzie PHP op 06/01/2011 13:34:46
Hmmm... dat rewrite rule regeltje van die images vind ik wel irritant want dat geldt natuurlijk voor alle document types en dat zijn er een stuk of 40. Wat gebeurt er als ik een niet gevonden plaatje toch door het framework stuur? Kan ik dan via het framework een "niet gevonden" pagina aanroepen?
Klopt, maar dat kost je performance. De meest gebruikte media types gaan via .htaccess, als iemand <iets>.<langerareextensie> aanroept gaat het via het framework. Daar ontkom je niet aan.
[color="red"]- Oke, maar ik wil voorkomen dat bij iedere aanroep gecontroleerd moet worden of aan een van de 40 bestandstypen wordt voldaan. Vandaar dat ik het liever door het framework stuur. Echter stel nu dat er een image wordt aangeroepen met een niet bestaand plaatje? Dus <img src="bestaatniet.jpg" />. Wat gebeurt er dan met die url? Wordt die alsnog naar het framework gestuurd? Of is de browser zo slim dat ie dat niet doet (aangezien het om een plaatje gaat)?[/color]
Ozzie PHP op 06/01/2011 13:34:46
Tot nu toe heb ik dan dus dit... klopt er nu nog iets van? :-s
Mijn voorstel (P.S. denk om inspringen, commentaar):
[color="red"]- Moet je per se inspringen?[/color]
# Options
Options All -Indexes
# Configuration
AddDefaultCharset utf-8
# Rewriting
<IfModule mod_rewrite.c>
RewriteEngine On
# Allow GET, HEAD and POST
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
RewriteRule .* - [F]
# Forward to front controller
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?route=$1 [QSA,NC,L]
</IfModule>
Merk op dat ik ook <IfModule mod_dir.c> heb weggehaald, dit is nutteloos aangezien je -Indexes gebruikt, en standaard al naar index.php wordt gezocht (naar ik aanneem). Voor meer tips zie deze
[color="red"]- Wat heeft die -Indexes (geen directories tonen) te maken met de volgorde waarin naar index bestanden wordt gezocht? Ik had die ingesteld om te zorgen dat altijd index.php als eerste wordt aangeroepen (en niet index.htm(l) of default.htm(l))[/color]
site (NB je browser kan tijdelijk vastlopen alert).
[/quote]
Nog even terugkomend op het rewrite verhaal. Wat ik dus probeer is het volgende:
- stuur alles wat niet een bestand is OF wel een bestand is maar eindigd op htm, html, php, phml, ini of text door naar het framework.
Als het goed is komen er hierdoor alleen geldige routes of rechtstreekse aanroepen van webpagina's in het framework. Deze laatste zou ik moeten kunnen herkennen aan het feit dat er een punt . in de url zit. Zit er een punt in de url dan stuur ik deze door naar een niet gevonden pagina.
- wat betreft (media) bestanden (plaatjes, filmpjes maar ook documenten en zip bestanden) had ik het volgende bedacht: als het bestand bestaat en dus een geldig bestand is wordt het niet naar het framework gestuurd maar rechtstreeks aangeroepen. Echter, zoals jji aangaf kan er een bestand worden aangeroepen dat niet bestaat (in principe zou dit niet of niet vaak mogen voorkomen). Hij voldoet dan weer aan de rewrite rule en gaat dus weer het framework in. Ook dit keer zit er weer een punt . in de url en zou ik dus weer kunnen doorsturen naar een niet gevonden pagina.
Klopt deze gedachtegang? Die enkele keer dat er dan een niet bestaand bestand wordt aangeroepen wordt door het framework een niet gevonden pagina getoond. Indien tot zover nog alles klopt, gaat (zoals ik hierboven al vroeg) dit dan goed bij het tonen van een niet bestaande image?
Probeer zelf eens wat te prutsen ;) Maar bedenk wel, hoe complexer je het maakt hoe moeilijker het is om het te realiseren / af te handelen. Denk goed na voordat je het maakt. Ik heb over mijn CMS haast een half jaar na gedacht, en heb hier een stapel van ongeveer 20 A3 papieren met alle daarop uitgetekend. This nu alleen nog maar rammen :)
Wat is overigens het gehele resultaat van dit topic? Heb je al wat gerealiseerd?
Precies, daarom probeer ik door het telkens te herhalen, net als een leraar, bij jullie erin te pompen dat mijn kennisniveua op het gebied van DI nog niet zo hoog is als dat van jullie ;-)
Gaat vooral om een DI(c) de laatste pagina's. DI Zelf is heel simpel. Je hebt bijvoorbeeld een klasse en deze doet een aantal dingen, maakt helemaal niet uit wat, en heeft daar andere klassen bij nodig. Nu zijn daarvoor twee mogelijkheden. Je kan in een methode zelf een nieuwe instantie maken van een klasse, zie onderstaand voorbeeld:
<?php
public function __construct( )
{
$this->database = new Database( ... );
}
?>
Het nadeel hiervan is dat je niet vanaf buitenaf kan zien wat de relaties van de klassen zijn. Als tweede mogelijkheid kan je deze klasse die hij nodig heeft ook als parameter laten opgeven. Dan weet de gebruiker wel er nodig is om de klasse te laten werken. Zie onderstaand voorbeeld:
<?php
public function __construct( Database $database )
{
$this->database = $database;
}
?>
Dat is Dependency Injecton. Een Dependency Injection Container is dus iets anders als Dependency Injection zelf, al heeft het natuurlijk wel met elkaar te maken.
Dankjewel voor die link nogmaals, maar ik had gehoopt dat iemand op basis van mijn voorbeeldje van de webshop kan aangeven wat je met DI kunt doen
Nogmaals, probeer zelf wat ;-) Door zelf te doen leer je het best. Het maakt niet uit als je het gigantisch fout doet de eerst keer. Plaats je gerealiseerde code gewoon hier op het forum, wij reviewen die wel.
Thanks Niels. "Wat is overigens het gehele resultaat van dit topic? Heb je al wat gerealiseerd?" Nog niet veel :) maar ga het op m'n werk wel uitwerken. Thanks voor de uitleg over DI... weer een stukje wijzer!
Ik wil nu eerst mn htaccess fatsoenlijk werkend krijgen (zie hierboven) zodat ik verder kan met de rest van het framework, maar ik weet niet wat er nu wel en niet in moet. Kun jij er eens je licht op schijnen? Het enige wat lijkt te werken is de rewrite rule naar index.php. De rest doet geen zak :|
Nu staat dat htaccess bestand wel op een Windows server (volgens mij ISS) en werkt htcaccess alleen als ASP ondersteuning staat aangevinkt. Zou het daar mee te maken hebben dat niet alles werkt?
Thanks Niels. "Wat is overigens het gehele resultaat van dit topic? Heb je al wat gerealiseerd?" Nog niet veel :) maar ga het op m'n werk wel uitwerken. Thanks voor de uitleg over DI... weer een stukje wijzer!
Eigenlijk juist wel veel, je hebt naar mijn weten je kennis haast verdubbeld of heb ik dat mis ?:)
Over DI(c):
Zoals ik al eerder in dit topic heb gezegd ben ik bezig met een tutorial over dependency injection. Ik hoop deze over een week of 2 hier online te zetten ben al een behoorlijk eind :)
@Htaccess
Ik gebruik altijd simpelweg deze, en die voldoet aan mijn wensen:
php_flag magic_quotes_gpc Off
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php [L]
"Eigenlijk juist wel veel, je hebt naar mijn weten je kennis haast verdubbeld of heb ik dat mis ?:)" Haha... qua code nog niet veel gerealiseerd ;) Maar wel lekker m'n kennis aan het opveizelen inderdaad. Moet het nog wel in de praktijk brengen ;)
Da's een korte htaccess :-))))
Kun je nog iets zeggen iver mijn versie...
Options All -Indexes
AddDefaultCharset utf-8
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
