[PHP] Form action php_self

[Rusky]

Ik heb een iritant probleem.
Ik heb een html form met daarin php code die waarden uit database haalt.
Wanneer een submit wordt gedaan wordt verwezen naar php_self. Bovenin in deze
php_self staat de php code die de gegevens vanuit de Post in me database zet (na controle of deze wel voldoet).
Dit gaat allemaal super, en werkt 100%.

Alleen wanneer ik 'terug' kom op de pagina en de waarden in de database gezet zijn. worden niet de de waarden in de form geupdatet. Ik moet eerst weer de pagina refreshen voordat ik ze ook daadwerkelijk zie.
Kan dat niet direct gebeuren? Dat wanneer ik een submit doe, direct de waarden zie?

Voorbeeld code:
Code is wel uitgebreider ed... ik heb een hoop zooi weggehaalt, om de opzet duidelijker te maken.

PHP:

<?php

include 'lightcontrol/queries.php';

if (!empty($_POST['automatisch'])) {

    $automatisch =  $_POST['automatisch'];
    $ID = $_POST['ID'];

    mysql_query("UPDATE lightcontrol SET Vakantie='".$automatisch."' WHERE ID=".$ID."", $link);
}

while ($row = mysql_fetch_array($sql_select_all)){ 
    echo "<form action='vakantie.php' method='POST'>";  
        echo "<tr>";
            echo "<td>";
                echo "<select name='automatisch'>";
                    echo "<option value='uit'>Uit</option>";
                    echo "<option value='aan'>Aan</option>";
                echo "</select>";
                        echo "</td>";
            echo "<input type='hidden' name='ID' value='". $row['ID'] . "'>";
            echo "<td> <input type='submit' value='Submit'> </td>";
        echo "</tr>";
    echo "</form>";
    } 
?>

</table>

edit:
php tags gebruikt ipv code

[RM-rf]

als je de ge-update waardes wilt gebruiken in je pagina, zul je de sql SELECT- query moeten uitvoeren _na_ je UPDATE... (ik nem aan dat de mysql_query die $sql_select_all genereert al in 'lightcontrol/queries.php' zit)

nu haal je enkel een waardes-array uit een al bestaande mysql result-resource, die al bestond voor je update

[Rusky]

@RM-rf : Heel stom, maar is inderdaad zo .... bedankt! Helemaal over het hoofd gezien ...

[NMe]

Waar hoort mijn topic?

WEB>>PRG

[DonKui]

Misschien niet geheel gerelateerd aan je probleem maar de manier waar je op het moment met SQL omgaat is nogal gevoelig voor SQL Injection. Kan bijvoorbeeld client side heel makkelijk het ID veld aanpassen. Kan bijvoorbeeld opgelost worden door gebruik van http://nl3.php.net/mysql_real_escape_string of PDO

[DogEatsDog]

DonKui schreef op woensdag 15 januari 2014 @ 12:36:
Misschien niet geheel gerelateerd aan je probleem maar de manier waar je op het moment met SQL omgaat is nogal gevoelig voor SQL Injection. Kan bijvoorbeeld client side heel makkelijk het ID veld aanpassen. Kan bijvoorbeeld opgelost worden door gebruik van http://nl3.php.net/mysql_real_escape_string of PDO

Sowieso mysql_* niet meer gebruiken, overstappen naar mysqli_ of inderdaad, PDO.

[Rusky]

DogEatsDog schreef op woensdag 15 januari 2014 @ 15:53:
[...]

Sowieso mysql_* niet meer gebruiken, overstappen naar mysqli_ of inderdaad, PDO.

Ik moet mijn code toch nog helemaal doorlopen. Dan zal ik dit ook veranderen.
1 voordeel, dit is alleen voor thuis gebruik, dus achter gesloten router.
Maar ik wil inderdaad alsnog wel een veilige code gebruiken. Het is voor mij alweer een tijd geleden dat ik mysql gebruikte, en volgens mij waren die andere er toen helemaal niet.

Maar welke is nu veiliger / makkelijker? mysqli of PDO?

[royduin]

Kijk hier eens: http://net.tutsplus.com/t...qli-which-should-you-use/

[HuHu]

Wat je ook kunt doen is na het updaten van je tabel met een header() je gebruiker doorsturen naar een nieuwe (of dezelfde) pagina. Als de gebruiker de uiteindelijke pagina ververst, dan is er niets aan de hand. In de huidige situatie zal bij een druk op F5 de POST opnieuw worden verzonden.

[Rusky]

HuHu schreef op donderdag 16 januari 2014 @ 09:09:
In de huidige situatie zal bij een druk op F5 de POST opnieuw worden verzonden.

ik gebruik

PHP:

unset ($_POST['']);

maar die had ik niet genoemd in mijn startpost.
(had al genoemd dat ik wat eruit had gehaald

[HuHu]

Dat verhelpt, volgens mij, niet dat een browser het POST verzoek opnieuw zal versturen bij een refresh.

[Rusky]

HuHu schreef op donderdag 16 januari 2014 @ 09:29:
Dat verhelpt, volgens mij, niet dat een browser het POST verzoek opnieuw zal versturen bij een refresh.

Hmmm als ik refresh doet hij niks meer met de database ... dus zal het wel doen. Besides that, ik loop de code toch door op functionaliteit.

royduin schreef op donderdag 16 januari 2014 @ 09:05:
Kijk hier eens: http://net.tutsplus.com/t...qli-which-should-you-use/

Lekker discussie daar , de een zegt PDO omdat dat veel breder in te zetten is. De ander mysqli omdat deze veel gerichter werkt.
Ik denk dus dat ik mysqli pak en dan OOP daarmee ga leren programeren. Heb ik dat ook een keer gedaan.

[NMe]

Rusky schreef op donderdag 16 januari 2014 @ 09:55:
[...]

Hmmm als ik refresh doet hij niks meer met de database ... dus zal het wel doen. Besides that, ik loop de code toch door op functionaliteit.

Je postvariabelen unsetten heeft geen enkel effect op het F5-en. Je browser doet dan een nieuwe post waarbij het formulier nog eens verstuurd wordt.

Lekker discussie daar , de een zegt PDO omdat dat veel breder in te zetten is. De ander mysqli omdat deze veel gerichter werkt.

Niet zo gek. Het zijn twee verschillende dingen met twee verschillende scopes. Ik kan op dezelfde manier zeggen dat Doctrine beter is dan MySQLi en PDO bij elkaar omdat Doctrine veel meer kan. Stiekem heb je daar in kleine projectjes niks aan.

Overigens zou ik me niet te veel voorstellen van het hele OOP-verhaal van MYSQLi. Als je zelf verder alsnog gewoon procedureel programmeert ben je niet echt met OOP bezig.

[HuHu]

Rusky schreef op donderdag 16 januari 2014 @ 09:55:
[...]

Hmmm als ik refresh doet hij niks meer met de database ... dus zal het wel doen. Besides that, ik loop de code toch door op functionaliteit.

Dat komt omdat je de database nog een keer update met dezelfde inhoud. Er gebeurd dus (effectief) niets, maar de POST wordt wel degelijk opnieuw verzonden. Een (onwetende) bezoeker van je website krijgt ook zo'n melding van de browser dat er gegevens opnieuw verzonden gaan worden en die kan het effect ervan niet inschatten. Beter dus om het te vermijden.

[Cartman!]

Rusky schreef op donderdag 16 januari 2014 @ 09:27:
[...]
ik gebruik

PHP:

unset ($_POST['']);

maar die had ik niet genoemd in mijn startpost.
(had al genoemd dat ik wat eruit had gehaald

De site waar je deze 'truc' vandaan hebt zou ik uit je geschiedenis verwijderen en nooit meer opnieuw opzoeken...

[NMe]

Cartman! schreef op donderdag 16 januari 2014 @ 11:32:
[...]

De site waar je deze 'truc' vandaan hebt zou ik uit je geschiedenis verwijderen en nooit meer opnieuw opzoeken...

Inderdaad. Ik zat eerder mobiel dus kon er niet makkelijk op ingaan maar je $_POST-superglobal bestaat sowieso alleen binnen de scope van je script. Als je script klaar is en dus je pagina gerenderd wordt, wordt die array vernieuwd. Het is niet alsof je vervolgens bij een nieuw GET-request nog steeds een gevulde $_POST-array hebt.

Tenzij je op de een of andere manier iets persist (bijvoorbeeld op je filesystem of in een database) zijn er verdraaid weinig dingen die je in een request kan doen die in een volgend request nog steeds benaderbaar zijn.

[DonKui]

Beste is het op te lossen door een POST te doen welke een REDIRECT terug geeft waarnaar de client een GET actie doet naar een pagina en als je gebruiker dan refreshed dan voert hij een GET uit naar de betreffende pagina en niet een POST.

[ Voor 14% gewijzigd door DonKui op 16-01-2014 13:11 ]