• Developers
  • API callback without domain name or certificate

De huidige API callbacks eisen https met een geldig certificaat. Om een callback te ontvangen heb je dus een full-blown webserver nodig, een certificaat en een echte domein naam.

Een veel eenvoudiger opzet is een python "wsgiref.simple_server" script. Dit hoef je alleen op te starten en luistert daarna op een bepaalde poort. Zo'n eenvoudige opzet kan echter geen https aan.

Is het mogelijk om een nieuw callback type te maken, dat http toestaat, en dat alleen een trigger stuurt "er is een transactie geweest" zonder verdere informatie? B.v. een NOTIFY callback naast de huidige MUTATION.

    Is het nou echt zoveel meer werk om een basic Python of NodeJS servertje neer te zetten die een gratis letsencrypt certificaat gebruikt? ¯\_(ツ)_/¯

    Http traffic is gewoon niet meer van deze tijd, zeker niet als het om bankzaken gaat. Dus ik zou het een beetje tijdverspilling vinden van bunq als ze tijd moet besteden aan het aanbieden van een aparte callback die alleen via http werkt

      Inderdaad of zet het achter een CloudFlare Argo tunnel. Dan heb je de voordelen van een webserver met goede HTTPS, maar eigenlijk serve je gewoon vanaf je laptop in de trein.

        Inderdaad, of via ngrok.com .

        Andere opties zijn:

        - Goedkope Linux VPS bij DigitalOcean of Vultr, vanaf $ 5,- p/maand.

        - Goedkope hosting bij bijvoorbeeld Vimexx, vanaf € 4,49 heb je daar al hosting+domein+HTTPS/SSL.

          Klinkt allemaal leuk, maar niet heel toegankelijk? Het mooie van de oplossing die Wessel voorstelt is dat het ook een mogelijkheid is voor mensen (hoi, dat ben ik) die iets minder thuis zijn in netwerkbeheer :)

            Let's Encrypt is gratis. Ook voor wildcard certificaten; je kunt die dan zelf gemakkelijk gebruiken op een andere omgeving/systeem.


            Alternatief is bijvoorbeeld Comodo, daar vraag je een gratis certificaat aan zonder de ACME challenge.


            Zo'n certificaat kun je direct gebruiken in biivoorbeeld nginx, Caddy, lighttpd enzovoorts voor een reverse proxy, of direct in een node/Python webapp.


            Persoonlijk ben ik er wel voorstander van het 'enforcen' van deze eis. Is toch net wat extra veiligheid. Jij weet het misschien goed te firewallen en te configureren, dat gaat lang niet voor iedereen op 😉

              17 days later

              As an update to this request: computers behind a NAT router cannot technically present a valid certificate.

              It turns out that you can just listen to incoming TCP connections and use that as a callback. Bunq will retry the call 5 times because of the missing certificate but otherwise it works fine. https://github.com/wesselt/bunq2ynab/blob/master/auto_sync.py

                I don't see why not. My NAS box is behind NAT, it provides several ssl-secured vhosts through port forwarding.

                This seems like a security concern, does bunq provide data even when the certificate is absent or invalid?

                  I think he is simply checking if an incoming request was received and then manually checking the API instead of receiving actual data from the callback

                    Most people are behind a domain like "ip-123-123-123-123.ip.prioritytelecom.net" which you cannot present a certificate for, because you don't own Priority Telecom.

                      Write a Reply...