eigen framework / beheersysteem
Pagina: « vorige 1 2 3 ... 5 6 7 8 9 10 11 12 volgende »
Niels Kieviet op 05/01/2011 20:47:47:
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 ;-)Dit zeg je haast elke post :) Je kan het gewoon aanleren het is niet iets wat je hokuspokus erin gepompt krijgt :) Wat dacht je hoe een leraar het doet?
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. Dit is voor mij een stuk makkelijker te begrijpen omdat ik daar wat meer in thuis ben. Ik denk dat dan het kwartje pas echt gaat vallen. Maar goed, ik kan me ook voorstellen dat je geen zin hebt om dat uit te werken hoor :)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
<?php
// dit hele stuk is in weze je config bestand.
$container; // dat daar is mijn container
$container->add('pdo', function() {
return new PDO('...');
})
$container->add('database', function($c) {
return new Database($c->pdo);
});
$container->add('winkelwagentje', function($c) {
return new Winkelwagentje($c->sessie, $c->producten);
});
$container->add('producten', function($c) {
return new Producten_Store($c->database);
});
if (SITE_ENV == 'development')
{
// In m'n test-omgeving zijn PHP's sessies niet betrouwbaar omdat er allemaal sites op hetzelfde domein zitten,
// en dus allemaal dezelfde sessie delen wat gewoon raar is. Dus terugvallen op een speciale database sessie.
// (niet echt, maar het is een excuus om een if-then-else in de configuratie te laten zien)
$container->add('sessie', function($c) {
return new Sessie_Database($c->database);
});
}
else
{
$container->add('sessie', function() {
return Sessie_PHP::getInstance(); // hey, een singleton! Ja, want meerdere Sessies die allemaal gebruik maken van $_SESSION is vreemd, dus er kan maar één native sessie zijn, en dat is deze.
});
}
// tot hier. Einde configuratie.
abstract class Controller
{
protected $container;
public function __construct($container)
{
$this->container = $container;
}
}
// bedenk wel dat dat wat hierboven staat maar één keer moet
class Controller_Winkelwagen extends Controller
{
public function actionAddProduct()
{
$product = $this->container->producten->get($_POST['product_id']);
$winkelwagentje = $this->container->winkelwagentje;
$winkelwagentje->addProduct($product);
echo 'Jeej, product toegevoegd :D';
echo 'In je winkelwagentje zit nu:';
foreach ($winkelwagentje->producten() as $product)
echo $product->naam() . '<br>';
}
}
?>
// dit hele stuk is in weze je config bestand.
$container; // dat daar is mijn container
$container->add('pdo', function() {
return new PDO('...');
})
$container->add('database', function($c) {
return new Database($c->pdo);
});
$container->add('winkelwagentje', function($c) {
return new Winkelwagentje($c->sessie, $c->producten);
});
$container->add('producten', function($c) {
return new Producten_Store($c->database);
});
if (SITE_ENV == 'development')
{
// In m'n test-omgeving zijn PHP's sessies niet betrouwbaar omdat er allemaal sites op hetzelfde domein zitten,
// en dus allemaal dezelfde sessie delen wat gewoon raar is. Dus terugvallen op een speciale database sessie.
// (niet echt, maar het is een excuus om een if-then-else in de configuratie te laten zien)
$container->add('sessie', function($c) {
return new Sessie_Database($c->database);
});
}
else
{
$container->add('sessie', function() {
return Sessie_PHP::getInstance(); // hey, een singleton! Ja, want meerdere Sessies die allemaal gebruik maken van $_SESSION is vreemd, dus er kan maar één native sessie zijn, en dat is deze.
});
}
// tot hier. Einde configuratie.
abstract class Controller
{
protected $container;
public function __construct($container)
{
$this->container = $container;
}
}
// bedenk wel dat dat wat hierboven staat maar één keer moet
class Controller_Winkelwagen extends Controller
{
public function actionAddProduct()
{
$product = $this->container->producten->get($_POST['product_id']);
$winkelwagentje = $this->container->winkelwagentje;
$winkelwagentje->addProduct($product);
echo 'Jeej, product toegevoegd :D';
echo 'In je winkelwagentje zit nu:';
foreach ($winkelwagentje->producten() as $product)
echo $product->naam() . '<br>';
}
}
?>
En nu weer even zonder DI. Niet helemaal eerlijk, het is hier nu veel kleiner maar dit moet je dan op iedere plek waar je deze objecten nodig hebt herhalen en onthouden, en als je het wilt aanpassen of dynamisch wilt maken (wat ik nu heb gedaan met de sessie class) is het helemaal niet meer bij te houden.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<?php
class Controller_Winkelwagen extends Controller
{
public function actionAddProduct()
{
$pdo = new PDO(...);
$db = new Database($pdo);
if (SITE_ENV == 'development')
$sessie = new Sessie_Database($db);
else
$sessie = Sessie_PHP::getInstance();
$producten = new Producten_Store($db);
$winkelwagentje = new Winkelwagentje($sessie, $producten);
// diezelfde initialisatie, maar dan moet dat overal?
$product = $producten->get($_POST['product_id']);
$winkelwagentje->addProduct($product);
echo 'Jeej, product toegevoegd :D';
echo 'In je winkelwagentje zit nu:';
foreach ($winkelwagentje->producten() as $product)
echo $product->naam() . '<br>';
}
}
?>
class Controller_Winkelwagen extends Controller
{
public function actionAddProduct()
{
$pdo = new PDO(...);
$db = new Database($pdo);
if (SITE_ENV == 'development')
$sessie = new Sessie_Database($db);
else
$sessie = Sessie_PHP::getInstance();
$producten = new Producten_Store($db);
$winkelwagentje = new Winkelwagentje($sessie, $producten);
// diezelfde initialisatie, maar dan moet dat overal?
$product = $producten->get($_POST['product_id']);
$winkelwagentje->addProduct($product);
echo 'Jeej, product toegevoegd :D';
echo 'In je winkelwagentje zit nu:';
foreach ($winkelwagentje->producten() as $product)
echo $product->naam() . '<br>';
}
}
?>
Nu begint het te dagen...
Als je nu een framework zou maken, dan zou het configuratie gedeelte dus eigenlijk een onderdeel zijn van je applicatie? Correct?
Nog een paar vragen over dit stukje:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
$container->add('pdo', function() {
return new PDO('...');
})
$container->add('database', function($c) {
return new Database($c->pdo);
});
$container->add('winkelwagentje', function($c) {
return new Winkelwagentje($c->sessie, $c->producten);
});
$container->add('producten', function($c) {
return new Producten_Store($c->database);
});
?>
$container->add('pdo', function() {
return new PDO('...');
})
$container->add('database', function($c) {
return new Database($c->pdo);
});
$container->add('winkelwagentje', function($c) {
return new Winkelwagentje($c->sessie, $c->producten);
});
$container->add('producten', function($c) {
return new Producten_Store($c->database);
});
?>
Zou je me kunnen uitleggen wat je hier (ongeveer) doet? Eerst voeg je 'pdo' toe aan de container. Wat is dan de inhoud van 'pdo'? Vervolgens voeg je 'database' toe aan de container met daarin 'pdo'? Wat houdt function($c) precies in?
Als je nu $container->database aanroept krijg je dan telkens een new Database terug? Of is dat telkens dezelfde?
Thanks voor je code tot zover... heb het gevoel dat ik weer een stapje verder ben :)
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
$container->add('database', 'bouw_mijn_database');
// er gebeurt niets bijzonders
$x = $container->database;
// daaar pas wordt bouw_mijn_database() aangeroepen, omdat $container een instantie van database nodig heeft
$y = $container->database;
// $container heeft al een instantie van database, en hergebruikt die. $x === $y dus.
?>
$container->add('database', 'bouw_mijn_database');
// er gebeurt niets bijzonders
$x = $container->database;
// daaar pas wordt bouw_mijn_database() aangeroepen, omdat $container een instantie van database nodig heeft
$y = $container->database;
// $container heeft al een instantie van database, en hergebruikt die. $x === $y dus.
?>
In de posts hiervoor gebruikte ik een feature uit PHP 5.3, anonieme functies. Maar je kan ook gewoon de functienaam in een string er neerzetten.
Hoe $container precies is geïmplementeerd staat een paar pagina's terug. Ik heb mijn variant ervan daar ergens gepost, en Pimple, die ongeveer hetzelfde werkt, is ook al een paar keer voorbij gekomen. Die $c verwijst weer terug naar de $container, zodat de factory functies, die een instantie moeten bouwen, ook weer diezelfde container kunnen gebruiken om instanties van andere classes op te vragen. Dat $container->database werkt komt door de magic method __get, je zou ook $container->__get('database') ipv $container->database kunnen schrijven.
PDO is gewoon PDO, een database abstraction layer van PHP. Je kan natuurlijk ook MySQLi oid gebruiken als je dat makkelijker vindt. De class Database gebruik ik zelf graag om PDO heen, PDO heeft alleen maar PDO::prepare($sql) en PDO::query($sql), waarin je uitgebreid SQL moet schrijven. Voor inserts en updates is me dat teveel typwerk en Database::insert($table, array $fields) is dan makkelijker. Ook niet noodzakelijk of perce goed OOP, maar ik vind het wel praktisch en ik had wat vulling nodig voor mijn voorbeeld. (Een voorbeeld van hoe je die Database class zou kunnen implementeren staat in dit gastenboek voorbeeld)
Gewijzigd op 06/01/2011 00:20:15 door Jelmer -
Mijn PHP versie is kleiner dan 5.3, volgens mij 5.1 of 5.2. Zou ik dan bijvoorbeeld ook dit kunnen doen?
// $container->add('naam van de variabele', 'naam van class', 'construct parameters');
$container->add('database', 'Database', 'pdo');
- wat wordt er ge-add: 'database'
- wat wordt gereturned bij het opvragen: new Database
- met welke parameters in de construct: $container->pdo
Zou dat zo kunnen?
Die verwijzing zou je nog zo kunnen oplossen, waarbij $container->reference($naam) een of andere speciale waarde teruggeeft die hij weer kan herkennen wanneer hij Database gaat bouwen:
$container->add('database', 'Database', $container->reference('pdo'))
Ik denk eigenlijk dat dan terugvallen op create_function, hoe ranzig dat ook lijkt, makkelijker is. Dit komt uit een site waar ik nu mee aan het spelen ben (eentje zonder autoloading zoals je ziet ;) )
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?php
$container->add('pdo', create_function('', '
$pdo = new PDO("...", "...", "...");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
return $pdo;'));
$container->add('db', create_function('$container', '
require_once "lib/database.php";
return new Database($container->pdo);'));
$container->add('authentication', create_function('$container', '
require_once "lib/authentication.php";
return new Authentication($container->users);'));
$container->add('users', create_function('$container', '
require_once "lib/user.php";
return new User_Store($container->db);'));
?>
$container->add('pdo', create_function('', '
$pdo = new PDO("...", "...", "...");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
return $pdo;'));
$container->add('db', create_function('$container', '
require_once "lib/database.php";
return new Database($container->pdo);'));
$container->add('authentication', create_function('$container', '
require_once "lib/authentication.php";
return new Authentication($container->users);'));
$container->add('users', create_function('$container', '
require_once "lib/user.php";
return new User_Store($container->db);'));
?>
Situatie 1 (pdo wordt meegegeven aan 'database'):
$container = new Container();
$container->add('pdo', 'PDO');
$container->add('database', 'Database', $container->pdo);
Situatie 2 ($config wordt meegegeven aan 'database'):
$container = new Container();
$config = array($db_name, $db_pass, $db_host, $db_table);
$container->add('database', 'Database', $config);
Kun je als je tijd hebt overigens eens schieten op m'n htaccess bestand? Klopt dit (voor zover jij kunt zien?). Of staat er teveel of te weinig in? Of dingen die niet kloppen?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Options All -Indexes
AddDefaultCharset utf-8
<IfModule mod_rewrite.c>
RewriteEngine On
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>
<Limit COPY DELETE GET LOCK MOVE POST PUT UNLOCK>
order deny,allow
deny from all
</Limit>
AddDefaultCharset utf-8
<IfModule mod_rewrite.c>
RewriteEngine On
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>
<Limit COPY DELETE GET LOCK MOVE POST PUT UNLOCK>
order deny,allow
deny from all
</Limit>
Hier dezelfde code, maar nu met commentaar regels erbij:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Options All -Indexes // zorgt dat er geen directory kan worden opgevraagd
AddDefaultCharset utf-8 // default characterset op utf-8
<IfModule mod_rewrite.c> // kijk of de rewrite module werkt, zo ja ga verder
RewriteEngine On // zet de rewrite engine aan
RewriteCond %{REQUEST_FILENAME} !-f [OR] // verwijst de url niet naar een bestand...
RewriteCond %{REQUEST_FILENAME} .(inc|ini|p?ht.*|php.*|txt)$ // of verwijst de url naar een bestand dat eindigt op inc ini (p)ht* php* txt...
RewriteRule ^(.*)$ index.php?route=$1 [QSA,NC,L] // verwijs de url dan door naar index.php
</IfModule>
// van het onderstaande ben ik niet geheel zeker...
<Files ~ "\.(inc|ini|p?ht.*|php.*|txt)$"> // hou requests tegen die eindigen op .inc .ini .(p)ht* .php* of .txt. (dit lijkt overigens totaal niet te werken)
order allow,deny
deny from all
</Files>
<Limit COPY DELETE GET LOCK MOVE POST PUT UNLOCK> // zorg dat bepaalde acties niet kunnen worden uitgevoerd bij een niet-browser aanroep (weet niet of dit wel klopt)
order deny,allow
deny from all
</Limit>
AddDefaultCharset utf-8 // default characterset op utf-8
<IfModule mod_rewrite.c> // kijk of de rewrite module werkt, zo ja ga verder
RewriteEngine On // zet de rewrite engine aan
RewriteCond %{REQUEST_FILENAME} !-f [OR] // verwijst de url niet naar een bestand...
RewriteCond %{REQUEST_FILENAME} .(inc|ini|p?ht.*|php.*|txt)$ // of verwijst de url naar een bestand dat eindigt op inc ini (p)ht* php* txt...
RewriteRule ^(.*)$ index.php?route=$1 [QSA,NC,L] // verwijs de url dan door naar index.php
</IfModule>
// van het onderstaande ben ik niet geheel zeker...
<Files ~ "\.(inc|ini|p?ht.*|php.*|txt)$"> // hou requests tegen die eindigen op .inc .ini .(p)ht* .php* of .txt. (dit lijkt overigens totaal niet te werken)
order allow,deny
deny from all
</Files>
<Limit COPY DELETE GET LOCK MOVE POST PUT UNLOCK> // zorg dat bepaalde acties niet kunnen worden uitgevoerd bij een niet-browser aanroep (weet niet of dit wel klopt)
order deny,allow
deny from all
</Limit>
Gewijzigd op 06/01/2011 09:21:17 door Ozzie PHP
Ozzie PHP op 06/01/2011 09:19:14:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Options All -Indexes
AddDefaultCharset utf-8
<IfModule mod_rewrite.c>
RewriteEngine On
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>
<Limit COPY DELETE GET LOCK MOVE POST PUT UNLOCK>
order deny,allow
deny from all
</Limit>
AddDefaultCharset utf-8
<IfModule mod_rewrite.c>
RewriteEngine On
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>
<Limit COPY DELETE GET LOCK MOVE POST PUT UNLOCK>
order deny,allow
deny from all
</Limit>
Op het eerste gezicht:
- de "All" bij Options zou ik weglaten.
- Tweede RewriteCond is overbodig, zoals al eerder gezegd. Je zet immers alleen toegankelijke bestanden in de webroot, al het overige gaat erbuiten.
- Om bovenstaande reden is <Files> ook niet nodig.
- Je zou eventueel een RewriteRule kunnen toevoegen voor media bestanden, zodat deze niet via het framework gaan indien ze een 404 geven.
- De <Limit> is niet nodig, sowieso vraag ik me af of het werkt. Het lijkt nu alsof je bijvoorbeeld GET en POST niet toestaat. Dat lijkt me niet de bedoeling. Bovendien kan het geen kwaad als er een DELETE request wordt gedaan, zolang je deze niet ondersteunt. Je zou eventueel een RewriteRule kunnen toevoegen voor die alle requests met niet-geïmplementeerde methoden een 405 (Method not allowed) teruggeeft.
Gewijzigd op 06/01/2011 11:45:49 door Mark PHP
Mark PHP op 06/01/2011 11:38:36:
Op het eerste gezicht:
- de "All" bij Options zou ik weglaten.
Ik dacht ergens te lezen dat die All voor alle onderliggende directories geldt ofzo... maar weghalen dan maar?
- Tweede RewriteCond is overbodig, zoals al eerder gezegd. Je zet immers alleen toegankelijke bestanden in de webroot, al het overige gaat erbuiten.
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?
- Om bovenstaande reden is <Files> ook niet nodig.
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?)
- Je zou eventueel een RewriteRule kunnen toevoegen voor media bestanden, zodat deze niet via het framework gaan indien ze een 404 geven.
Wat bedoel je precies? Media bestanden gaan nu toch sowieso niet via het framework?
- De <Limit> is niet nodig, sowieso vraag ik me af of het werkt. Het lijkt nu alsof je bijvoorbeeld GET en POST niet toestaat. Dat lijkt me niet de bedoeling. Bovendien kan het geen kwaad als er een DELETE request wordt gedaan, zolang je deze niet ondersteund. Je zou eventueel een RewriteRule kunnen toevoegen voor die alle requests met niet-geïmplementeerde methoden een 405 (Method not allowed) teruggeeft.
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 :)
- de "All" bij Options zou ik weglaten.
Ik dacht ergens te lezen dat die All voor alle onderliggende directories geldt ofzo... maar weghalen dan maar?
- Tweede RewriteCond is overbodig, zoals al eerder gezegd. Je zet immers alleen toegankelijke bestanden in de webroot, al het overige gaat erbuiten.
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?
- Om bovenstaande reden is <Files> ook niet nodig.
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?)
- Je zou eventueel een RewriteRule kunnen toevoegen voor media bestanden, zodat deze niet via het framework gaan indien ze een 404 geven.
Wat bedoel je precies? Media bestanden gaan nu toch sowieso niet via het framework?
- De <Limit> is niet nodig, sowieso vraag ik me af of het werkt. Het lijkt nu alsof je bijvoorbeeld GET en POST niet toestaat. Dat lijkt me niet de bedoeling. Bovendien kan het geen kwaad als er een DELETE request wordt gedaan, zolang je deze niet ondersteund. Je zou eventueel een RewriteRule kunnen toevoegen voor die alle requests met niet-geïmplementeerde methoden een 405 (Method not allowed) teruggeeft.
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 :)
Gewijzigd op 06/01/2011 11:58:29 door Ozzie PHP
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.
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.
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.
Ozzie PHP op 06/01/2011 11:53:35:
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.
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:
Code (php)
1
2
3
2
3
# Allow GET, HEAD and POST
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
RewriteRule .* - [F]
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.
Gewijzigd op 06/01/2011 12:09:32 door Mark PHP
Mark PHP op 06/01/2011 12:08:37:
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
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
#
# 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>
# 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>
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:
Klik. Het kan niet heel veel kwaad als je All laat staan, persoonlijk gebruik ik het nooit.
- Oke dan laat ik m 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.
- 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?
Dan werkt je hele framework toch niet meer. Bovendien heb je nog steeds geen beschermde bestanden in de webroot staan, dus overbodig blijft het.
- Je framework kan dan nog steeds werken alleen wordt je route dan www.mijnsite.nl/?route=kantoorartikelen/nietmachines ipv www.mijnsite.nl/kantoorartikelen/nietmachines. (uiteraard wil je dit niet, maar als het echt niet anders kan...). Maar die hele FILES lijkt niks te doen. Doe ik daar iets verkeerd?
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?)
- 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.
Klik. Dit klopt inderdaad niet :-) Wil je methoden blokken, dit werkt:
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.
-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?
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.
- Oke dan laat ik m staan.
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.
- 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?
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.
- Je framework kan dan nog steeds werken alleen wordt je route dan www.mijnsite.nl/?route=kantoorartikelen/nietmachines ipv www.mijnsite.nl/kantoorartikelen/nietmachines. (uiteraard wil je dit niet, maar als het echt niet anders kan...). Maar die hele FILES lijkt niks te doen. Doe ik daar iets verkeerd?
Ozzie PHP op 06/01/2011 11:53:35:
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?)
- 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.
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:
Code (php)
1
2
3
2
3
# Allow GET, HEAD and POST
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
RewriteRule .* - [F]
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.
-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?
Gewijzigd op 06/01/2011 12:28:54 door Ozzie PHP
Ozzie PHP op 06/01/2011 12:26:52:
Je framework kan dan nog steeds werken alleen wordt je route dan www.mijnsite.nl/?route=kantoorartikelen/nietmachines ipv www.mijnsite.nl/kantoorartikelen/nietmachines. (uiteraard wil je dit niet, maar als het echt niet anders kan...). Maar die hele FILES lijkt niks te doen. Doe ik daar iets verkeerd?
Die <Files> heb je daar helemaal niet voor nodig.
Ozzie PHP op 06/01/2011 12:26:52:
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.
Code (php)
1
2
3
2
3
# Handle media
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.(css|gif|jpe?g|js|png)$ - [L,R=404]
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?
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.
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
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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>
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>
Ozzie PHP op 06/01/2011 13:34:46:
Nogmaals, je hebt geen .html bestanden in je webroot staan, dus is die FILES niet 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.
Ozzie PHP op 06/01/2011 13:34:46:
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.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?
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):
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 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>
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).
Gewijzigd op 06/01/2011 13:57:04 door Mark PHP
Mark PHP op 06/01/2011 13:50:43:
- 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 :(
- 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)?
Mijn voorstel (P.S. denk om inspringen, commentaar):
- Moet je per se inspringen?
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
- 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))
site (NB je browser kan tijdelijk vastlopen alert).
Ozzie PHP op 06/01/2011 13:34:46:
Nogmaals, je hebt geen .html bestanden in je webroot staan, dus is die FILES niet 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.
- 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 :(
Ozzie PHP op 06/01/2011 13:34:46:
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.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?
- 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)?
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):
- Moet je per se inspringen?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 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>
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
- 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))
site (NB je browser kan tijdelijk vastlopen alert).
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?
Bedankt alvast weer voor je reactie!
Gewijzigd op 06/01/2011 14:15:44 door Ozzie PHP
Wat is overigens het gehele resultaat van dit topic? Heb je al wat gerealiseerd?
Quote:
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:
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:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
public function __construct( Database $database )
{
$this->database = $database;
}
?>
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.
Quote:
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.
Gewijzigd op 07/01/2011 20:57:12 door Niels K
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?
Gewijzigd op 07/01/2011 21:20:07 door Ozzie PHP
Quote:
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:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
php_flag magic_quotes_gpc Off
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php [L]
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php [L]
Da's een korte htaccess :-))))
Kun je nog iets zeggen iver mijn versie...
Code (php)
1
2
3
4
5
2
3
4
5
Options All -Indexes
AddDefaultCharset utf-8
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$ [NC]
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>
en de versie zoals Mark die voorstelde...
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 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>
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>
... of heb jij van htaccess net zo weinig kaas gegeten als ik?
Ik wil graag 1 top htaccess bestandje hebben die ik straks altijd kan gebruiken voor het framework.
Gewijzigd op 07/01/2011 22:13:35 door Ozzie PHP
Pagina: « vorige 1 2 3 ... 5 6 7 8 9 10 11 12 volgende »