Mollie webhook call bij lokaal development
De callback loopt bij Mollie sowieso van server naar server. Maar het staat 'een ander' natuurlijk vrij om de server ook via diezelfde achterdeur aan te pesten. Dat wil je voorkomen. Dat gebeurt dus 1) al omdat je zelf de payment gegevens bij Mollie ophaalt (dus iemand kan op de achterdeur kloppen met wat ie wilt, je haalt zelf de gegevens op, dus dat valt niet te faken), en 2) voor de zekerheid geef je nog een hash mee die ze niet weten + niet kunnen gokken.
Bij Sisow staat wel alle info in redir / client URL, en die wordt daar beveiligd door een hash mee te geven. Die hash gaat over alle data in de URL (id, status, enz) *en* nog een secret dat niet in de URL staat (maar wel aan beide zijde bekend is). Door deze hash dus na te rekenen kun je achterhalen of er met de URL geklooid is (= dus ook veilig).
Ward van der Put op 24/09/2017 12:38:16:
Je wilt sowieso niet de client een rol van betekenis geven. De callback met statusupdate moet daarom van server naar server lopen, niet via de client. Zolang je dat niet goed doet en de client-URL's gaat "beveiligen", tussen aanhalingstekens, heb je een tweederangs oplossing.
Je kan prima de client een GET laten doen en daar de check op uitvoeren hoor, je bent dan nog steeds zelf in control in je code, niets vreemds aan.
Je mist het punt: je kunt niet vertrouwen op de client, ook niet met met een hash van de requestparameters.
Ward van der Put op 24/09/2017 20:13:55:
In je code ben je altijd in control. Lijkt mij, want het is jouw code.
Je mist het punt: je kunt niet vertrouwen op de client, ook niet met met een hash van de requestparameters.
Je mist het punt: je kunt niet vertrouwen op de client, ook niet met met een hash van de requestparameters.
Je kan een client prima via een hashurl laten lopen, de rest doe je op de achtergrond...
Gewijzigd op 24/09/2017 22:10:11 door Wesley Rijnders
- Je hebt een stel params: $status, $id, $whatever; deze komen allemaal in de URL (GET) vanuit Sisow.
- Je hebt een $secret; die komt niet in de URL (maar beide zijden weten 'm).
- Sisow berekent een hash($status . $id . $whatever . $secret); die geven ze ook mee in de URL (GET).
- Aan de ontvangende kant maak je nu dezelfde som: hash($status . $id . $whatever . $secret) (eerste 3 uit de GET, secret weet je).
- Die controleer je met de hash uit de GET. Als die niet gelijk zijn weet je dus dat er geknoeid is met de $status, $id, of $whatever (en dat gebeurt regelmatig).
Mocht je hier toch mogelijkheden zien om daar omheen te komen, dan kun je vanaf nu gratis bestellen bij webshops die hun betalingen via Sisow laten lopen (gewoon Annuleren bij je bank, in de return URL status=Success zetten, en even zelf de hash uitrekenen). Succes(s) ...
Zo dus.
Ik heb het zelf ooit gehad dat de redirect vanuit ideal naar de webshop misliep: url was niet bereikbaar. Misschien een overbelasting bij de (best grote) webshop, of een hik van de server. In elk geval had ik wel betaald, maar dat was niet bekend bij de shop.
Klantenservice kon vervolgens na contact niet leveren. Wel uiteindelijk geld retour gekregen maar producten waren al uitverkocht. Kennelijk triggerde die shop ook alleen maar op "klant komt terug". Of dat dan inclusief de hash was, of dat er ook een server-to-server contact was geweest, weet ik niet. Wel dat de webshop er ten onrechte vanuit ging dat de klant per se terug komt na de de betaling.
Weet iemand waar Mllie de BetalingsId op baseert ? Het lijkt me dat er zeker wel duplicates in hun DB zitten namelijk en iedereen met die ID aan de haal kan gaan.
Zo'n 5 procent van de bezoekers die afrekenen met iDEAL, klikt in het laatste scherm niet op "terug naar de webwinkel". Nee, die sluiten gewoon het browservenster: betaald, klaar. Die GET met of zonder hash komt er dan dus nooit.
Maar geloof mij maar niet hoor. Doe maar wat.
- Initieel vertrouwen ze op de returnUrl, waarbij dus de hele rambam in 1x via de client wordt teruggeketst (met controle hash).
- Maar je kunt ook nog een callbackUrl meegeven waarmee ze een server-to-server terugkoppeling doen. Maar die komt dus vaak pas 'een tijdje later' (een kwartier klinkt wel herkenbaar).
Maar dat moet de webshop bouwert dan dus wel ingebouwd hebben. Je moet het nl apart aangeven op het moment dat je een payment link aanvraagt bij Sisow, en dat gebeurt idd niet altijd. Waardoor je dus bij sommige webshops niet moet vergeten om "terug naar de webwinkel" te klikken.
En zo zijn er natuurlijk ook nog legio webshops die die hele hash niet controleren en dus echt op de data in de GET vertrouwen. Dan kun je dus op "Annuleren" klikken bij je bank, en vervolgens zelf "Success" in de URL typen ...
Mollie (meer ervaring heb ik ook niet met payment providers) voelt wat meer doordacht+degelijker. Maar komt dus ook wat meer bij kijken. Als je al via Composer werkt is het gewoon een regeltje d'r bij, maar voor Sisow hoef je maar één file te includen (meer is er ook niet).
Sisow zal dus voor een beginner heel snel op te pakken zijn, maar omdat het zo makkelijk is, en niets hoeft, laat je ook makkelijk gaten vallen (hash niet controleren, geen registratie als de klant niet "terug naar webshop" klikt = gezeik).
Een beetje zoals de gemiddelde vragensteller hier altijd roept dat ze "de beveiliging later wel op orde maken" als ze op SQLi e.d. gewezen worden (met een SSL certificaat) ;-)
Rob Doemaarwat op 25/09/2017 19:04:51:
Sisow doet beide:
- Initieel vertrouwen ze op de returnUrl, waarbij dus de hele rambam in 1x via de client wordt teruggeketst (met controle hash).
- Maar je kunt ook nog een callbackUrl meegeven waarmee ze een server-to-server terugkoppeling doen. Maar die komt dus vaak pas 'een tijdje later' (een kwartier klinkt wel herkenbaar).
- Initieel vertrouwen ze op de returnUrl, waarbij dus de hele rambam in 1x via de client wordt teruggeketst (met controle hash).
- Maar je kunt ook nog een callbackUrl meegeven waarmee ze een server-to-server terugkoppeling doen. Maar die komt dus vaak pas 'een tijdje later' (een kwartier klinkt wel herkenbaar).
Aha, nu begrijp ik het: je moet inderdaad haast wel de return-URL gebruiken als de callback zo idioot lang op zich laat wachten. Dat is gewoon niet werkbaar anders!
Daarin was in de procdure vastgelegd, dat in principde de callback eerst kwam.
Maar ik ben niet 100% zeker of die callback daar ook bestond.
Maar komt je klant eerder terug dan de callback, dan moest je zelf de status opvragen.
Was die niet Success of Failure, en dus nog iets van "bezig", dan moest je gedurende 24 uur (of meer) op intervallen van een half uur of zo, steeds pollen of de status al definitief was.
En was het "success", dan alsnog de bestelling in werking stellen en klant mailen.
Dat kan de vertraging van een kwartier ook verklaren.
Nadeel was, dat je scripts voor een Rabobank klant net niet helemaal werkten als de volgende klant (als in klant voor de websitebouwer) bij de Abn zat.
En dan had Rabo vlak daarna ook een tussenvorm Internetkassa.
Maar uiteindelijk werkt het mi. via Mollie en dergelijke partijen het fijnst, omdat je dan naast iDeal ook nog zo vele andere methoden kunt aanvinken. Zonder al je scripts om te gooien