Hoe krijg je berichten vanuit de url in een alert

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Senior Cyber Defense Analyst

We are looking for a Senior Cyber Defense Analyst Responsibilities: Design, develop, test and support code providing detection and automation capabilities for cyber security toolsets; Creation of alert, report and search capabilities using advanced data analytic toolsets for cyber defense activities; Provide cyber defense related input to the design and participate in the implementation of cyber security capabilities for internal projects; Participate in complex investigations and threat hunting; Acquire knowledge of changing technologies and threats to provide recommendations for adaptation of technologies or policies; Design, create, organise and deliver staff training, update knowledge management databases and document procedures; Qualifications: Bachelor's

Bekijk vacature »

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

Bekijk vacature »

Martijn Schuman

Martijn Schuman

06/10/2019 19:52:34
Quote Anchor link
Ik ben bezig met een inlog systeem, ik ben nu bezig met 'error handelers'. Stel een gebruiker vult een gebruikersnaam in die al in gebruik is wordt hij terug gestuurd naar de signup pagina met het volgende in de url. localhost/paginas/systeem/signup.php?Gebruikersnaam_in_gebruik . Is het mogelijk om alles achter het '?' in een standaard alert box te krijgen of een mooiere html/css alert box? Ik heb online op andere website ook al gekeken, daar gebruiken ze GET om de informatie te krijgen. Dit kan, maar ik krijg het werkend met maar 1 error code. Ik heb in totaal 4 error berichten die weergeven kunnen worden. Namelijk: Database_verbinding_mislukt/Lege_velden/Gebruikersnaam_in_gebruik/Email_in_gebruik.
 
PHP hulp

PHP hulp

17/10/2019 13:21:36
 
- Ariën -
Beheerder

- Ariën -

06/10/2019 20:17:33
Quote Anchor link
Met welke reden zou je een GET willen gebruiken om een error op te roepen?
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 -
 
Rob Doemaarwat

Rob Doemaarwat

06/10/2019 21:41:36
Quote Anchor link
Wat Ariën bedoelt is: waarom zou je dit via de GET willen laten lopen? Ik neem aan dat alles op een en dezelfde website komt. Dan kun je de foutmeldingen gewoon in de SESSION opslaan, en bij de eerste volgende weergave van "een" pagina (de signup pagina) geef je die weer (en verwijder je ze weer uit de SESSION).

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").
 
- Ariën -
Beheerder

- Ariën -

06/10/2019 21:45:01
Quote Anchor link
Tuurlijk, maar zonder GET is het minder lucreatiever voor phishers, en zullen gebruiker sneller argwaan krijgen, omdat ze nog op een vreemde site zitten. Ikzelf vind GET los van dit gewoon niet geschikt, omdat je prima via POST dit kan afhandelen. In een SESSION kan je eventueel nog opslaan wat iemand vergeten is in te vullen, zodat je dit nog kan laten oplichten of iets dergelijks.
 
Thomas van den Heuvel

Thomas van den Heuvel

06/10/2019 22:09:54
Quote Anchor link
De gebruiker zou nooit een POST pagina te zien moeten krijgen. Dat zou inhouden dat je output produceert terwijl je een formulier aan het verwerken bent. Dit soort acties (het tonen van een formulier, het verwerken van het formulier, een resultaatpagina na succesvolle verwerking) zouden alle in afzondering, dus compleet gescheiden, behandeld moeten worden. Dat is in vele opzichten vele malen "cleaner". Ook is het een goede gewoonte om met maximaal één handeling tegelijkertijd bezig te zijn. Een formulier on-the-fly verwerken terwijl je iets anders aan het uitdraaien bent verzandt al snel in een vormloze codebrei.

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
 
Frank Nietbelangrijk

Frank Nietbelangrijk

07/10/2019 00:55:40
Quote Anchor link
>> De gebruiker zou nooit een POST pagina te zien moeten krijgen.

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

07/10/2019 14:58:32
Quote Anchor link
Maar dat impliceert dat je een verwerk-actie (serverside zonder output) voor/tijdens een weergave-actie regelt (output). En wat is dan de impact als je heen en weer gaat navigeren? Wat als je succesvol dingen submit en dan een stap terug gaat in de historie? Het kan wel, maar het is een rare spagaat. Uit oogpunt van "Eén ding tegelijkertijd" zou ik hier niet aan beginnen. Je zult sowieso meer administratie moeten regelen omtrent formulieren dan je in eerste instantie zou denken (CSRF token enzo), dus kun je het wellicht beter in één keer "goed" opzetten. Vooral als je veel formulieren in je applicatie hebt. Dit werk verdient zich dan (steeds) snel(ler) terug.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

07/10/2019 19:42:38
Quote Anchor link
>> En wat is dan de impact als je heen en weer gaat navigeren?
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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.