[PHP] Funcie die(); heeft geen effect

[mrc4nl]

amoi! iedereen, ik ben voor me zelf een CMS aan het schijven.
details doen er niet echt toe.

-wat is het probleem?
op mijn LAMP instalatie is er èèn pagina die geen text output wil geven aan de browser.
terwijl ie dat wel hoort te doen.

Ook al ik in de 1e regel de functie

PHP:

die("kijk eens aan eindelijk wat text!");

plaats, blijft mn browserscherm leeg. er ik ook geen broncode .


dat is mijn punt juist, de functie die() stopt toch het script en laat alleen zien wat er in die() staat?

wat er in de rest van het script staat dan mag niet schelen...

oja- en ik heb het maar op èèn server gestest en die blijft falen

hier mn hele script:

PHP:

*snip*

[Voor 97% gewijzigd door RobIII op 07-07-2011 00:11]

[apokalypse]

wat is het relevantie van die +300 regels code?

[FastPinguin]

Als ik dat eerste stukje code exact overneem dan krijg ik gewoon de tekst van de functie die. De code klopt gewoon...

[mrc4nl]

mmm, ik sluit het niet uit maar kan mijn webserver/php soms gewoon van slag zijn?
is natuurlijk ook een optie, de 2e include haal ik weg..

[CodeCaster]

Zet errors aan en zie dat je op regel 56 een fout hebt, die wordt veroorzaakt op regel 55...

SoulWar1 schreef op donderdag 07 juli 2011 @ 00:11:
Met zo'n stuk code zou ik geen CMS gaan schrijven maar een PHP boek kopen

[Voor 74% gewijzigd door CodeCaster op 07-07-2011 00:12]

[SoulWar1]

Met zo'n stuk code zou ik geen CMS gaan schrijven maar een PHP boek kopen

[mrc4nl]

CodeCaster schreef op donderdag 07 juli 2011 @ 00:10:
Zet errors aan en zie dat je op regel 56 een fout hebt...

t kan zijn dat ik die idd uitgeschakeld heb, maar dan nog. als ik een die() plaats horen errors erna toch niet meer door de post processor te gaan?

[PatrickH89]

Een die wordt ook niet uitgevoerd in het geval er een error in je script staat, ookal staat die later dan de die.

[RobIII]

mrc4nl schreef op woensdag 06 juli 2011 @ 23:57:
hier mn hele script:

PHP:

*snip*

Ja, doei
Debuggen mag je zelf doen. Als je code post, post dan enkel relevante(!) delen. Enorme lappen code zijn dus niet gewenst.

SoulWar1 schreef op donderdag 07 juli 2011 @ 00:11:
Met zo'n stuk code zou ik geen CMS gaan schrijven maar een PHP boek kopen

Het klinkt lullig maar hier sluit ik me volledig bij aan. Deze, toch wel stinkende, hoop code is op vele, vele punten voor verbetering vatbaar...

[Voor 36% gewijzigd door RobIII op 07-07-2011 00:13]

[Thralas]

Neem overigens ook even https://www.owasp.org/index.php/SQL_Injection door..

[mrc4nl]

ja dat had ik ook al door maar nu is mn hele code weg? heb ik dat zelf gedaan?
nu is mn hele code is in geen geval relevant:/

*mrc4nl heeft moeite met rustog te blijven, zoveel reacties in zo kote tijd kanniet goedgaan*


en wat heeft sql injection er mee te maken?
(zoveelste)edit ah ok
. ik ga later aandacht aan veiligheid besteden, t is meer project om van te leren, echte websites gaan hosten hoef ik niet

en ik heb voordat ik begon met schijven van een csm ook eerst een boek van de bieb geleed om php te leren.
dat statium ben ik nu voorbij.

[Voor 87% gewijzigd door mrc4nl op 07-07-2011 00:19]

[RobIII]

Thralas schreef op donderdag 07 juli 2011 @ 00:13:
Neem overigens ook even https://www.owasp.org/index.php/SQL_Injection door..

Ik zag zo snel nergens user input in een query verdwijnen, van SQL injection mogelijkheden was (voor zover ik zag) niet direct sprake.

[Thralas]

RobIII schreef op donderdag 07 juli 2011 @ 00:15:
[...]

Ik zag zo snel nergens user input in een query verdwijnen, van SQL injection mogelijkheden was (voor zover ik zag) niet direct sprake.

Er werd ergens een $map gebruikt welke rechtstreeks uit de database kwam. Als je die value in de database kunt aanpassen dan is 't feest.. (reflected SQLi, persistent SQli, geen idee hoe 't heet).

[RobIII]

Thralas schreef op donderdag 07 juli 2011 @ 00:16:
[...]


Er werd ergens een $map gebruikt welke rechtstreeks uit de database kwam. Als je die value in de database kunt aanpassen dan is 't feest.. (reflected SQLi, persistent SQli, geen idee hoe 't heet).

Ja, ik zie/zag 't nu ook (lang leve diffs ). Indirect kan er inderdaad wel SQL injection plaatsvinden. En gezien de code die TS tentoonspreidde denk ik dat 'elders' waar de DB gevuld wordt die SQL injection ook niet voorkomen wordt. Dus de mogelijkheid is er zeer zeker (los van 't feit dat je eigenlijk altijd sowieso moet escapen).

mrc4nl schreef op donderdag 07 juli 2011 @ 00:14:

en ik heb voordat ik begon met schijven van een csm ook eerst een boek van de bieb geleed om php te leren.
dus

Was dat een PHP3 of PHP4 boek?
Want seriously, dit is code die men in '96 als voorbeelden gaf in boeken. Dit is anno 2011 echt niet meer te verdedigen. Sorry.

[Voor 58% gewijzigd door RobIII op 07-07-2011 00:21]

[CodeCaster]

En dat moet je dan dus escapen op het moment dat je het in de database stopt, niet op het moment dat je het eruit haalt.

@hieronder: true.

[Voor 28% gewijzigd door CodeCaster op 07-07-2011 00:25]

[RobIII]

CodeCaster schreef op donderdag 07 juli 2011 @ 00:18:
En dat moet je dan dus escapen op het moment dat je het in de database stopt, niet op het moment dat je het eruit haalt.

Ja, maar als je dit doet:

code:

$records = execute_qry('select foo, bar from mytable where...')
foreach $records as $r
  $something = execute_qry('select x, y from sometable where x = $r->foo')

dan ga je alsnog de mist in En dat is wat er gebeurde. Je kunt dan heel mooi bij het inserten escapen, maar als je de values uit de DB dan weer rechtstreeks in andere queries mikkert is de kans op SQL injection natuurlijk net zo groot (maar: indirect).

mrc4nl schreef op donderdag 07 juli 2011 @ 00:14:
ik ga later aandacht aan veiligheid besteden, t is meer project om van te leren, echte websites gaan hosten hoef ik niet

Om mezelf even te quoten:

quote: http://robiii.tweakblogs....d-der-blinden-part-3.html

Veiligheid is niet iets wat je, nadat je (bijna) klaar bent met je site, even "inbouwt" of als nieuwe laag ergens "boven op legt". Zelfs al verkeert je site nog in Betafase, sterker, Alpha-stadium, dan nog horen dit soort zaken gewoon niet meer voor te komen. Het hoort, vanaf het moment dat je de code produceert, voorzien te zijn.

mrc4nl schreef op donderdag 07 juli 2011 @ 00:14:
(zoveelste)edit ah ok

Euh; je hoeft niet steeds je bericht te editten
Alleen als je de laatste poster in 't topic bent en je wil iets toevoegen gebruik je de de edit knop ( ); je topic herhaaldelijk omhoogschoppen is niet nodig. Maar daar wordt je vanzelf op gewezen als je dit ziet:

Heeft er iemand na je gepost dan post a.u.b. weer gewoon daaronder; het wordt er nu niet bepaald leesbaarder op

[Voor 70% gewijzigd door RobIII op 07-07-2011 00:28]

[mrc4nl]

zucht ik heb blijkbaar nog een hoop te leren

RobIII schreef op donderdag 07 juli 2011 @ 00:21:
Euh; je hoeft niet steeds je bericht te editten
Alleen als je de laatste poster in 't topic bent en je wil iets toevoegen gebruik je de de edit knop ( [afbeelding] ); je topic herhaaldelijk omhoogschoppen is niet nodig. Maar daar wordt je vanzelf op gewezen als je dit ziet:

[afbeelding]

Heeft er iemand na je gepost dan post a.u.b. weer gewoon daaronder; het wordt er nu niet bepaald leesbaarder op

ja is wel beter, maar voordat ik een post had gemaakt werden er al weer nieuwe berichten geplaatst,
dit tempo ben ik nog niet eerder op t.net tegengekomen

maar laten we het als het even kan bij de fuctie die() houden, sql injection enz komen we misschien later op terug.

hier een voorbeeltje: met express wat fouten:

PHP:

<?php
// Report all PHP errors (see changelog)
error_reporting(E_ALL);
die("test");


$vage fout = 1 =3
{moet niet uitmaken}

?>

bij MIJ blijft de webpagina wederom leeg.
terwijl alk ik enkel en allen die() zou gebruiken ik wel normaal output krijg.

is dit een interpret fout van php?
gaat ie soms door na die()?

[Voor 44% gewijzigd door mrc4nl op 07-07-2011 00:31]

[RobIII]

mrc4nl schreef op donderdag 07 juli 2011 @ 00:28:
hier een voorbeeltje: met express wat fouten:

PHP:

<?php
// Report all PHP errors (see changelog)
error_reporting(E_ALL);
die("test");


$vage fout = 1 =3
{moet niet uitmaken}

?>

Dat geeft een "Parse error: syntax error"; PHP gaat al op z'n bek bij 't "bekijken/analyseren" (parsen (nl)) van je script; laat staan dat 'ie begint met het uitvoeren ervan waarbij 'ie dan pas een die() zou uitvoeren.

mrc4nl schreef op donderdag 07 juli 2011 @ 00:28:
bij MIJ blijft de webpagina wederom leeg.
terwijl alk ik enkel en allen die() zou gebruiken ik wel normaal output krijg.

is dit een interpret fout van php?
gaat ie soms door na die()?

Ik ken de exacte ins/outs van PHP/apache niet dus 't zou kunnen dat er in de php.ini iets staat van display_errors = 'off' ofzo. Ik zou daar dan eens naar gaan kijken: en dan doe ik [google=php display errors] en holy crap Batman! Gewoon de eerste hit raak. Waarom lukt dat bij jou niet?

[Voor 39% gewijzigd door RobIII op 07-07-2011 00:35]

[mrc4nl]

RobIII schreef op donderdag 07 juli 2011 @ 00:30:
[...]

Dat geeft een "Parse error: syntax error"; PHP gaat al op z'n bek bij 't "bekijken/analyseren" (parsen) van je script; laat staan dat 'ie begint met het uitvoeren ervan waarbij 'ie dan pas een die() zou uitvoeren.

dankje RobIII daar ging het mij vooral om. ik dacht dat dat() gewoon je script stopde op de regel, maar verdere parse errors hebben dus wel invloed.

en ik moet denk ik mn lamp opniew instaleren, ik zie blijkbaar geen errors meer, wat ook niet echt bevorderend is voor debugging... ook met error reporting on.

[CodeCaster]

mrc4nl schreef op donderdag 07 juli 2011 @ 00:28:
gaat ie soms door na die()?

Ja natuurlijk, want op het moment dat 'ie dat tegenkomt is 'ie alleen nog maar aan het proberen te begrijpen wat jij hebt ingetikt: hij is aan het parsen, of interpreteren. Als dat is gelukt, gaat 'ie de gelezen code pas uitvoeren. Je die() wordt dus nooit uitgevoerd, want het parsen mislukt al, omdat je syntax incorrect is.

[Voor 1% gewijzigd door CodeCaster op 07-07-2011 00:39. Reden: En Rob tikt weer eens sneller.]

[RobIII]

mrc4nl schreef op donderdag 07 juli 2011 @ 00:35:
dankje RobIII daar ging het mij vooral om. ik dacht dat dat() gewoon je script stopde op de regel, maar verdere parse errors hebben dus wel invloed.

die() stopt ook je script. Er zijn geen "verdere parse errors". Heel de die() wordt nooit uitgevoerd omdat PHP al op z'n bek gaat bij het lezen/begrijpen van je script.

Dit is wat een interpreter als (bijv.) PHP (grofweg) doet:
[list=1]
• bestand.php openen/van schijf lezen
• parsen (begrijpend lezen zeg maar)
• script uitvoeren

Het gaat al fout in stap 2. De die() zou pas worden uitgevoerd in stap 3 maar heel stap 3 bereikt 'ie nooit omdat 'ie in 2 al op z'n plaat is gegaan.

mrc4nl schreef op donderdag 07 juli 2011 @ 00:35:
en ik moet denk ik mn lamp opniew instaleren, ik zie blijkbaar geen errors meer, wat ook niet echt bevorderend is voor debugging... ook met error reporting on.

Ja joh! Gebruik even een Howitzer voor een mug Loop gewoon je php.ini eens na; klik voor de gein eens op de link die ik gaf.

[Voor 21% gewijzigd door RobIII op 07-07-2011 00:54]

[NMe]

...en koop gewoon écht even dat boek. Je bent nu in het wilde weg aan het schieten op alles dat beweegt maar intussen raak je alleen bejaarden en kleine kinderen terwijl de spreekwoordelijke terrorist nog vrolijk rondloopt. Je focust op de verkeerde dingen.

[RobIII]

NMe schreef op donderdag 07 juli 2011 @ 00:42:
...en koop gewoon écht even dat boek.

_{emphasis mine}
Alsjeblieft niet!
Koop een goed boek!

[mrc4nl]

NMe schreef op donderdag 07 juli 2011 @ 00:42:
...en koop gewoon écht even dat boek. Je bent nu in het wilde weg aan het schieten op alles dat beweegt maar intussen raak je alleen bejaarden en kleine kinderen terwijl de spreekwoordelijke terrorist nog vrolijk rondloopt. Je focust op de verkeerde dingen.

dat het geen voorbeeld is van hoe het zou moeten geef ik je 100% gelijk in,
maar in het wilde weg schieten zeker niet, ik loop doelgericht met de hand te coderen

een boek zal helpen, maar ik kan ook op internet naslag vinden,
de grondbeginselen ken ik echt wel.

en vergis je niet, het HEEFT prima gewerkt, maar door al dat handcode en geen versiebeheer is er ergens een fout ingekomen en die moet ik op zien te zoeken.

over een paar maanden post ik wel het hele script, kunnen jullie mijn werk ook eens bekijken.

[Voor 6% gewijzigd door mrc4nl op 07-07-2011 00:56]

[RobIII]

mrc4nl schreef op donderdag 07 juli 2011 @ 00:54:

over een paar maanden post ik wel het hele script, kunnen jullie mijn werk ook eens bekijken.

We doen hier niet aan sitechecks noch rate-my-code™ Dus spaar je de moeite Als je een concreet programmeerprobleem hebt is (relevante delen!) code altijd welkom; als je code wil posten om "te showen" zit je hier aan 't verkeerde adres. Daarbij, en geloof me, ik bedoel 't beschermend: je gaat niet vrolijk worden van de reacties als 't er allemaal uitziet zoals de code in je TS

[Voor 43% gewijzigd door RobIII op 07-07-2011 00:58]

[mrc4nl]

RobIII schreef op donderdag 07 juli 2011 @ 00:55:
[...]

We doen hier niet aan rate-my-code Dus spaar je de moeite

slechtste programmervoorbeelden topic

ach er is vast wel ruimte ergens, anders nog wel extern.

[RobIII]

mrc4nl schreef op donderdag 07 juli 2011 @ 00:58:
slechtste programmervoorbeelden topic

Snippets ja; geen lappen spaghetti-code van honderden regels.

mrc4nl schreef op donderdag 07 juli 2011 @ 00:58:
ach er is vast wel ruimte ergens, anders nog wel extern.

Ook linkjes naar pastebin etc. worden niet op prijs gesteld als de geposte code niet enkel bestaat uit een relevant deel voor een concreet probleem zoals ik net beschreef. Het extern zetten van de code verandert daar niets aan.

Maar goed: zullen we weer ontopic a.u.b.?

[Voor 15% gewijzigd door RobIII op 07-07-2011 01:01]

[mrc4nl]

RobIII schreef op donderdag 07 juli 2011 @ 00:59:
[...]

Snippets ja; geen lappen spaghetti-code van honderden regels.


[...]

Ook linkjes naar pastebin etc. worden niet op prijs gesteld als de geposte code niet enkel bestaat uit een relevant deel voor een concreet probleem zoals ik net beschreef. Het extern zetten van de code verandert daar niets aan.

shure... ga je gang met het verwijderen van extere linkjes: Post hier je eigen Android App!
dat zijn ook programma's

ik wil het topic heus niet veruilen, maar ergens op tweakers is een plaatsje. conform de regels

dat hoeft echt niet onder programming te staan. de huiskamer of blog kan ook.

maar laten we het vriendelijk houden, ik heb wat geleerd. t zou zonde zijn als hier alsnog een slotje op komt.

[Voor 6% gewijzigd door mrc4nl op 07-07-2011 01:07]

[Shrimp O Vis]

Mag ik vragen waarom je je eigen CMS gaat maken? In de devschuur coffee corner ging het er hier nog over

[mrc4nl]

dat mag je best vragen hoor

als allereerst om leren te programmeren, een project omzetten.
2e, de doelstelling was zonder database pagina's kunnen. maken ,aanpassen en verwijderen

ik kon met de file schijf lees instructies de boel aanpassen, maar om ook nog eens alle mappen te scannen op pagina's was te veel van het goede.

later heb ik toch maar mysql connecties toegevoegd om dat makkelijker is voor pagina's in verschillende mappen, en een login systeem.

wat nog lang niet af is.

[Shrimp O Vis]

Ah ok dan is het goed Sommigen maken een eigen CMS omdat ze te "lui" zijn om wordpress of joomla te leren terwijl dat uiteindelijk je zelfs tijd oplevert..(lijkt me)

[Voor 7% gewijzigd door Shrimp O Vis op 07-07-2011 01:26]

[mrc4nl]

Shrimp O Vis schreef op donderdag 07 juli 2011 @ 01:25:
Ah ok dan is het goed Sommigen maken een eigen CMS omdat ze te "lui" zijn om wordpress of joomla te leren terwijl dat uiteindelijk je zelfs tijd oplevert..(lijkt me)

idd als je denk het beter te kunnen kom je bedrogen uit,
joopla en dupral zitten boordevol functies, maar daar heb je wel tjid nodig om alles onder de knie te krijgen.
ik heb voor de lol TYPO3 een keer gebruikt, een frontpage maken was bijna magie voor nodig...

ik vind dat de nieuwe cms'en turials moeten introduceren, veel gemakkelijker.
maar ja de laaste keer dat ik me daar mee bezig hield was ergens van drupdal 5 ofzo..