Hoe krijg je berichten vanuit de url in een alert
Dat een website die je hebt gevonden deze techniek toepast wil niet zeggen dat het de beste oplossing is?
Met wat jij wilt, daar kan prima misbruik van worden gemaakt bij phishing. Ze sturen je gewoon na het onderscheppen van je inloggegevens op een malafide site naar www.site.nl?error=loginincorrect en een gebruiker heeft gewoon de verwachting dat hij echt een verkeerd wachtwoord heeft ingevuld.
Zulke meldingen moet je na een actie zien, een actie je die via POST (en uiteraard SSL) verstuurd.
Gewijzigd op 06/10/2019 20:20:54 door - Ariën -
Dat met die phishing klopt wel een beetje, maar dan is het leed toch al geleden (de vissers hebben het wachtwoord al gevangen). Het is dus ook niet zo dat je je gebruikers er mee gaat beschermen door het niet te doen (en het is ook een techniek die je wel vaker voorbij ziet komen). Waar je meer op moet letten is dat je de melding uit de GET niet letterlijk in je popup gaat tonen. Niet alleen om te voorkomen dat iedereen allerlei teksten kan tonen, maar vooral om XSS (Cross Site Scripting) te voorkomen. Je zou bijvoorbeeld alleen een code mee kunnen geven, en op basis daarvan de juiste melding tonen (bijvoorbeeld ?msg=db levert "Geen database connectie").
Een gevolg hiervan is wel dat je informatie weer (terug) zult moeten overhevelen naar je formulier als in de verwerking de validatie niet slaagt. Dat, of je maakt gebruik van AJAX-requests, zodat je de formulier-pagina niet hoeft te verlaten zolang er niets succesvol gesubmit is.
Hoe dan ook, je querystring is hiervoor niet het ideale vervoermiddel. Noch met "magische constanten" (?error=5) noch met berichten (?error=gebrek_aan_koffie).
Zoals @Rob aangeeft kan een sessie uitkomst bieden. Ook als je je formulieren wat meer gaat standaardiseren en je hier bijvoorbeeld op den duur een formuliersysteem voor bouwt (zodat je uiteindelijk formulieren in elkaar kunt klikken in plaats van dat je elke keer alles opnieuw from scrach moet schrijven) dan kun je het gebruik van sessies hier ook in integreren.
Dit is dus ook een uitgelezen moment dat je gaat nadenken over hoe je in het algemeen webppagina's opbouwt en serveert en hoe de flow van formulierverwerking verloopt.
EDIT: als je iets POST, volg dan het POST/redirect/GET ontwerpprincipe.
Gewijzigd op 06/10/2019 22:12:26 door Thomas van den Heuvel
Mijn inziens kun je een formulier prima in de POST methode opnieuw laten zien met de foutmeldingen. Immers voer je dan nog geen acties uit die te maken hebben met de verwerking van de data uit het formulier (zoals de gegevens opslaan in de database). Heel erg belangrijk is inderdaad het redirecten direct na de verwerking van de formulier data.
Niets want de validatie mislukt (keer op keer).
>> Wat als je succesvol dingen submit en dan een stap terug gaat in de historie?
Inderdaad een formulier dat ten onrechte meerdere keren wordt ingediend en waarbij de input wordt goedgekeurd en klakkeloos wordt opgeslagen op de server (of wat voor actie dan ook) is natuurlijk onwenselijk. Maar ik zeg dus ook dat na een succesvolle submit zeker WEL een redirect moet volgen. In de geschiedenis staan dan enkel nog die POST aanroepen waarbij de validatie mislukt en die krijg je dan dus ook niet in het systeem geschoten.
>> Je zult sowieso meer administratie moeten regelen omtrent formulieren dan je in eerste instantie zou denken (CSRF token enzo)
Klopt. Die zit er bij mij dan ook standaard in. Overigens is het grootste probleem dat men soms meerdere keren op de verzend knop drukt en het request al meerdere keren verzonden wordt voordat de redirect zijn werk kan doen. Dit is hetgeen ook moeilijk uit te sluiten is net als iemand die gewoon bewust meerdere keren een formulier gaat invullen.
Er zijn mogelijkheden om herhalingen te voorkomen maar vaak zijn die niet waterdicht en wat er gedaan kan worden hangt af van de aard van het formulier.
Toevoeging op 07/10/2019 19:47:51:
Een aardige oplossing tegen een "bibberend handje" is een stukje javascript.