Problemen met header()
Om het overzichtelijk te maken heb ik het formulier in 3 stukken verdeeld.(alle drie zijn php files)
Aan het eind van het eerste formulier wordt met een insert opdracht een aantal gegevens weggeschreven in een database. Daarna wordt doorgeschakeld naar het tweede formulier. De code is als volgt:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
<?php
$sql = "INSERT INTO projecten (id, indiendatum, stichting, oprichting, anbi, website, stichtingdoel, contactpersoon, mailadres, telefoonnummer, kennisvandas, doelproject, inhoud)
VALUES('','$indiendatum','$_POST[stichting]','$_POST[oprichting]','$_POST[anbi]','$_POST[website]','$_POST[stichtingdoel]','$_POST[contactpersoon]','$_POST[mailadres]','$_POST[telefoonnummer]','$_POST[kennisvandas]','$_POST[doelproject]','$_POST[inhoud]')";
if ($conn->query($sql) === TRUE) {
$bericht .= "Er is een aanvraag1 gedaan voor een subsidie van de Stichting DAS";
$headers .= "From : Stichting DAS\r\n";
mail ("[email protected]", "Aanvraag t.b.v.Stichting Das ingestuurd", $bericht, $headers);
$last_id = $conn->insert_id;
$_SESSION["id"]= $last_id;
header('Location: ../html/invulformulier2.php');
?>
$sql = "INSERT INTO projecten (id, indiendatum, stichting, oprichting, anbi, website, stichtingdoel, contactpersoon, mailadres, telefoonnummer, kennisvandas, doelproject, inhoud)
VALUES('','$indiendatum','$_POST[stichting]','$_POST[oprichting]','$_POST[anbi]','$_POST[website]','$_POST[stichtingdoel]','$_POST[contactpersoon]','$_POST[mailadres]','$_POST[telefoonnummer]','$_POST[kennisvandas]','$_POST[doelproject]','$_POST[inhoud]')";
if ($conn->query($sql) === TRUE) {
$bericht .= "Er is een aanvraag1 gedaan voor een subsidie van de Stichting DAS";
$headers .= "From : Stichting DAS\r\n";
mail ("[email protected]", "Aanvraag t.b.v.Stichting Das ingestuurd", $bericht, $headers);
$last_id = $conn->insert_id;
$_SESSION["id"]= $last_id;
header('Location: ../html/invulformulier2.php');
?>
De overgang en het wegschrijven gaat zonder problemen.
Bij het tweede formulier maak ik gebruik van een update omdat ik de gegevens in 1 record wil hebben.
Ook dit gaat goed. De gegevens worden netjes weggeschreven maar dan ontstaat het probleem. Er wordt niet doorgeschakeld naar het derde formulier;
De code is:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
<?php
$teller=$_SESSION["id"];
$sql = "UPDATE projecten SET resultaat='$_POST[resultaat]', statusproject='$_POST[statusproject]' , lokalebetrokkenheid= '$_POST[lokalebetrokkenheid]', partners='$_POST[partners]', controle='$_POST[controle]', risico='$_POST[risico]', verantwoording='$_POST[verantwoording]' WHERE id= $teller";
if ($conn->query($sql) === TRUE) {
$bericht .= "Er is een aanvraag2 gedaan voor een subsidie van de Stichting DAS";
$headers .= "From : Stichting DAS<[email protected]>\r\n";
mail ("[email protected]", "Aanvraag t.b.v.Stichting Das ingestuurd", $bericht, $headers);
header('Location: http://www.stichting-das.nl/html/invulformulier3.php');
?>
$teller=$_SESSION["id"];
$sql = "UPDATE projecten SET resultaat='$_POST[resultaat]', statusproject='$_POST[statusproject]' , lokalebetrokkenheid= '$_POST[lokalebetrokkenheid]', partners='$_POST[partners]', controle='$_POST[controle]', risico='$_POST[risico]', verantwoording='$_POST[verantwoording]' WHERE id= $teller";
if ($conn->query($sql) === TRUE) {
$bericht .= "Er is een aanvraag2 gedaan voor een subsidie van de Stichting DAS";
$headers .= "From : Stichting DAS<[email protected]>\r\n";
mail ("[email protected]", "Aanvraag t.b.v.Stichting Das ingestuurd", $bericht, $headers);
header('Location: http://www.stichting-das.nl/html/invulformulier3.php');
?>
Heeft iemand een idee waarom de tweede keer niet wordt doorgeschakeld.
Als ik het test om mijn eigen computer en op een i-pad werkt het wel goed.
Edit:
Ik heb code-tags geplaatst. Gelieve dit in het vervolg zelf toe te voegen aan je bericht.
Zie ook: Veel gestelde vragen: Welke UBB-codes kan ik gebruiken.
Zie ook: Veel gestelde vragen: Welke UBB-codes kan ik gebruiken.
Gewijzigd op 05/03/2019 11:32:17 door - Ariën -
Ik gok dat je query mislukt. En let ook op SQL-injection. Iedereen kan je queries manipuleren. Zelf onbedoeld...
Gewijzigd op 04/03/2019 14:34:32 door - Ariën -
maar dan komt de Header() en die werkt niet
Ik vermoed dat er ergens een foutmelding optreedt. Dit kan output produceren. En dit kan op zijn beurt headers verstoren. Heb je je error logs al geraadpleegd?
Overigens hoort na een header('Location: ...'); eigenlijk altijd een exit-statement.
Dit omdat zo'n header je niet direct automagisch naar de nieuwe locatie stuurt (interne link, klik en lees).
Alle $_POST-waarden zouden in ieder geval geneutraliseerd moeten worden zodat deze niet als SQL geïnterpreteerd kunnen worden. Dit doe je met een escape-functie in combinatie met quotes.
Toevoeging op 04/03/2019 17:22:50:
Er worden behoorlijk grote teksten verstuurd door de clienten. Ze doen dat veelal met knippen en plakken. Dit heb ik nagebootst door de gegevens uit de database ook met knippen en plakken in het formulier te zetten en daar waar de client niet verder kan lukt dat bij mij moeiteloos.
Toevoeging op 04/03/2019 17:26:04:
De clienten krijgen geen mail. Dat is ook niet de bedoeling.
Maar het is toch te gek dat ze informulier 2 blijven hangen en telkens als ze op verzenden drukken krijg ik een mail. terwijl 1 regel verder de header() staat.
Code (php)
1
header('Location: ../html/invulformulier2.php');
Is dat niet degene waar het fout gaat? Het staat wel niet onderin maar dit lijkt mij geen geldige URL...
Daarom escaping!
Zet anders je foutafhandeling eens helemaal aan.
Gewijzigd op 05/03/2019 11:32:42 door - Ariën -
Dan het gegeven dat de huidige opbouw van de queries in ieder geval potentieel voor problemen kan zorgen.
En dan dus een onbekende oorzaak van het niet doorschakelen.
@Frank draagt ook een interessant punt aan: kloppen de paden wel? Weet je zeker dat je goed doorverwezen wordt? Als je het hebt over de eigen computer bedoel je dan ook een lokale (test/ontwikkel-)webserver of heeft dit alles enkel betrekking op de website http://www.stichting-das.nl/? Want in het ene geval gebruik je een relatieve doorverwijzing (wat officieel eigenlijk niet mag) en in het andere geval een absolute verwijzing.
Anyhow. Het heeft in ieder geval geen zin om een situatie te analyseren waarvan je weet dat deze niet klopt. Los eerst de fouten op, en kijk dan of het oorspronkelijke probleem nog speelt.
Concreet: escape alle DATA-delen in je SQL op een fatsoenlijke manier en zorg voor uniforme Location-URL's waarbij de voorkeur uitgaat naar volledige URL's en ga vervolgens na of de problemen nog spelen.
Je maakt tevens gebruik van sessies, die hun compleet eigen scala aan mogelijke problemen hebben. Roep je op elke pagina waar je sessies gebruikt ook session_start() aan? Daarnaast, je bent ook het id kwijt als iemand onverhoopt te lang over het invullen van het formulier doet omdat dan in de tussentijd je sessie is verlopen.
Gewijzigd op 05/03/2019 14:41:15 door Thomas van den Heuvel
Gewijzigd op 05/03/2019 15:31:42 door - Ariën -
Los van het feit of deze duur "lang genoeg" zou zijn om een formulier in te vullen zou dit nooit mogen resulteren in het verliezen van cruciale / eerder ingevulde informatie.
Dit omdat dit de verdere werking kan verstoren (auto increment id kwijt, woeps?) maar ook omdat dit gewoon ontzettend gebruiksonvriendelijk is.
Niets is zo vervelend als je aan het eind van de invulrit je ingevulde gegevens kwijt bent omdat het systeem hier niet in voorziet. Het systeem zou dus ook nooit zodanig ingericht mogen zijn dat dit uberhaupt een potentieel probleem is.
Ik denk zelf dat meerendeel van de sessie-gebaseerde formulieren niet beveiligd zijn tegen het verliezen van de sessie, omdat niemand tegen die lange tijd aanloopt. Zou jij anders voor die ene 0,0001% iets inbouwen?
Bij boekingssystemen voor ticket zie je wel vaak een afteller, maar dat is meer omdat die ook direct de plaats reserveert. Anders zou het sneu zijn dat je na je ingevulde formulieren te zien krijgt dat ze vol zitten.
Gewijzigd op 05/03/2019 16:13:44 door - Ariën -
- Ariën - op 05/03/2019 16:11:53:
Zou jij anders voor die ene 0,0001% iets inbouwen?
Nee, ik zou iets maken waarbij het niet uitmaakt of de sessie verloopt, en waarbij het tevens gegarandeerd is dat je geen data verliest op het moment dat je het formulier submit. Met name dat laatste lijkt mij het belangrijkste.
Wat zou jouw oplossing dan zijn? Een heartbeat-achtig iets in AJAX die elke xx seconden laat weten dat hij nog open staat in de browser.
- Ariën - op 05/03/2019 16:33:47:
Dus bouw je feitelijk wel wat voor dat mariginale aantal bezoekers. :P
Nee ik bouw iets wat gewoon altijd werkt. Ik snap de ":P" niet helemaal want ik zou geen code bouwen die in 0,0001% van de gevallen of wat dan ook met 100% zekerheid faalt.
- Ariën - op 05/03/2019 16:33:47:
Wat zou jouw oplossing dan zijn? Een heartbeat-achtig iets in AJAX die elke xx seconden laat weten dat hij nog open staat in de browser.
Nee, gewoon de sessie laten verlopen en doorstarten. Voor de goede orde zou je publieke formulieren moeten bewaken met een CSRF-token, maar die ben je dus ook kwijt als je sessie verloopt. Op het moment dat iemand dan submit zou je hem gewoon terug moeten sturen naar het formulier waarbij de formulierdata in de (opnieuw aangezwengelde) sessie wordt "gered". Je zou dan een melding moeten krijgen dat iemand even opnieuw zijn gegevens zou moeten evalueren en opnieuw moet submitten.
In het specifieke geval van @Peter waarbij hij zijn informatie-toevoer splitst over meerdere pagina's zal hij dus een andere manier moeten vinden om een invulsessie te propageren. Dit zou je bijvoorbeeld kunnen doen door een hash mee te sturen in de URL op het moment dat het eerste formulier is ingevuld ofzo, je moet op een of andere manier alle informatie bij elkaar houden. Dat, of een cookie ofzo.
Gewijzigd op 05/03/2019 16:44:50 door Thomas van den Heuvel
Er zijn nu eenmaal dingen die niet triviaal zijn omdat een zeer klein deel van de bezoekers tegen dat ene probleem loopt en omdat dat formulier ook misschien ook nog eens niet heel belangrijk is. In die tijd zijn er wel belangrijkere zaken op te lossen. Ik weet niet hoe jij een 'sessie doorstarten' ziet, maar ik zou voor een simpel contactformulier (als zou die met sessies werken) toch afwegen of het nuttig is om dit 100% van de mensen werkend te maken.
Elk applicatie heeft wel wat edge-cases die niet volledig goed zijn: een foutafhandeling (die zelden plaatsvindt) die zich niet beperkt tot een reeks verschillend meldingen maar tot een algemene melding. Een URL-parameter die een lege pagina geeft omdat iemand een onverwachte (onschuldige) waarde geeft, een database die net hikt op het moment dat je wat verstuurt.
Als je echt alles fool-proof wilt maken dan zul je echt extra tijd nodig hebben wat de boel ook duurder maakt. Kortom: Afwegingen maken. Als het voor de hobby is: Prima! Doe wat je wilt! Maar als je een deadline gaat stellen, dan is afwegingen maken ook zeker handig. Vooral als je perfectionist bent.... ;-)
Gewijzigd op 05/03/2019 18:05:14 door - Ariën -
Een website is ook een visitekaartje.
Het bovenstaande klinkt ook niet als een simpel contactformulier.
Een deadline hangt ook af van wat je bent overeengekomen wat je gaat maken, tenzij je niet-verplichte functionaliteit gaat strippen om een echte harde deadline te halen, tis maar net hoe en wat je hebt afgesproken.
Maar om nu op voorhand de kantjes er vanaf te lopen door functionaliteit te minimaliseren en iets op te leveren wat bij het minste of geringste stootje in elkaar lazert zegt toch meer over iemands ethos als programmeur dan iets anders. Dat is gewoon werk voor je uit schuiven. En als je op die manier iets ondeugdelijks oplevert krijgt je dit weer net zo hard op jouw bord teruggeboemerangd als je net met je volgende spoedklus bezig bent. Kun je het beter in 1x goed (of in ieder geval fatsoenlijk) doen.
Gewijzigd op 05/03/2019 18:06:41 door Thomas van den Heuvel
Thomas van den Heuvel op 05/03/2019 18:05:49:
Maar om nu op voorhand de kantjes er vanaf te lopen door functionaliteit te minimaliseren en iets op te leveren wat bij het minste of geringste stootje in elkaar lazert zegt toch meer over iemands ethos als programmeur dan iets anders.
Dat is trouwens niet wat ik zeg, en is behoorlijk opgeblazen als het een reactie op mij is. Uiteraard moet iets stabiel zijn dat iedereen er mee kan werken. Maar sommige edge-cases zijn niet echt belangrijk. Die zou ik zeker niet beschouwen als een ingrediënt voor een product wat ondeugdelijk is.
Als het maar functioneel is en niet een blokkade vormt voor de gebruiker. Anders is het wel ondeugdelijk.
Anyway, anyhow. Ik denk zelf dat het gewoon zinniger is om tussentijds de stappen alvast in de database op te slaan, want daar moet het uiteindelijk toch in. Maar ik ben nog steeds benieuwd hoe jij een sessie door wilt starten.
Gewijzigd op 05/03/2019 18:32:54 door - Ariën -