Add ability to receive POST requests to Apilio inbound webhooks functionality

webhooks
Add ability to receive POST requests to Apilio inbound webhooks functionality
0

#1

Today (June 19) Apilio only accepts GET requests from IFTTT and other services. Certain customers would appreciate the ability to send POST requests to Apilio.

A word on the HTTP method: Yes, currently you have to use GET. I know that this is not quite correct from a purist RESTful interpretation - actually, it should be implemented as PATCH method (https://tools.ietf.org/html/rfc5789). I chose GET to simplify the setup process for non-technical users (because GET might sound familiar to most).

https://groups.google.com/forum/#!topic/apilio/PRovworxSZk


#2

In my opinion this is a very interesting request!!

But i think that the more important reason is the security… With the GET resquest, any person in the middle of the communication can see the request and can execute it later…

I think only accept GET resquest is a big security problem…
If apilio accepts POST request, the key can pass in the body and over a HTTPS connection the data can’t be view for a middle person.

I understand that the GET option is available to facilitate configuration, but I believe that the POST option should be given to ensure a minimum of security.

Thanks for your excellent work with apilio!!


#3

Hi @Lobe,
we were able to integrate directly with IFTTT in the meantime and we are therefore encouraging users to migrate to that way of integrating.
We are trialing a more strict REST API that does not allow data updates via GET - you can check it out here: Apilio web API v1

But generally speaking, sending data via GET request is not as risky as many believe. Apart from the hostname, the URI and all data is in fact encrypted. A nice explanation is here: https://https.cio.gov/faq/#what-information-does-https-not-protect or of course directly at the source: https://www.ietf.org/rfc/rfc4366.txt


#4

The problem is that all the data at the moment of the suggestion (I don’t know how works now with the ifttt integration) navigated on the url… Any person in the middle can reproduce the request and turn on the light…


#5

But I don’t think that differentiates GET from POST requests.
The topic of replaying requests is not trivial and there is an interesting article on Cloudflare’s blog that also touches on it: https://blog.cloudflare.com/introducing-0-rtt/


#6

If you send a post request over https, the identifier of the user and the identifier of the var can send in the body of the request. This data isn’t visible for any person in the middle. The most important data is the user identifier.


#7

But that’s the same for a GET request. The path is not visible and any parameters are encrypted.


#8

I am just loving this ahem discussion chain!
:smile:


#9

Is not the same…
Get request example:
https://www.url.com/service/asdfasdfdsfsfgdg/MyVar

Post request example:
https://www.url.com/service
Body params:
asdfasdfdsfsfgdg
Myvar

In the first request (GET), the URL is completely visible so the parameters are visible and anyone in the middle, copying the URL into the browser can relaunch the request.
In the second (POST), if the request is about HTTPS, the url is visible but does not provide compromised information. The body of the petition will not be visible, so no one can reproduce the petition.

I’m sorry for my English, I didn’t expect to have to write so much … hehehe


#10

what a shame I can only do one “thumbs up”…


#11

:grin: Ok, @DanT. @Lobe and I stop it here. We agree to not agree :blush:


#12

@Lobe I think that means we won! :stuck_out_tongue_winking_eye: