[thelist] Webhook security

[Renoir Boulanger]

This my sound weird.

But have you thought of using AMQP for message transfer for your events.

I am currently doing, also, an ordering system and I also want it to be able to have dispersed workers.  In my case AMQP is the way to go.

But your requirement sound to make it, also, a good use case.

Opinion?



--
Renoir Boulanger
http://renoirboulanger.com/

(envoyé de mon téléphone)
~

Em 2012-08-28, às 14:22, Bill Moseley <moseley at hank.org> escreveu:

> On Tue, Aug 28, 2012 at 11:05 AM, Jay Turley <jayturley at gmail.com> wrote:
> 
>> If you made all the callbacks from JavaScript using AJAX, would the
>> built-in cross-domain policy prevent requests to a degree sufficient for
>> your purposes?
>> 
> 
> Not sure we are talking about the same thing.   Maybe webhook was the wrong
> term to use.
> 
> Imagine there's a RESTful web service where you can submit an order for
> processing and you want to know when the order was shipped.
> 
> One option is to poll the service to check if the item was shipped.
> 
> Another option is when you submit the order you include a URL that the
> service can later request when the order is shipped.  It's a notification
> of an event.
> 
> It's similar to PayPal's IPN callbacks, except that with IPN you have to
> call back to PayPal to authenticate that the data that was just sent by (we
> assume) PayPal.
> 
> My question is about ways to authenticate that the request is really coming
> from the right place without using something like PayPal's IPN that
> requires another request.
> 
> 
> 
> 
> 
>> 
>> -Jay
>> 
>> On Aug 28, 2012, at 9:52 AM, Bill Moseley <moseley at hank.org> wrote:
>> 
>>> I want to implement webhooks -- user-defined URL callbacks that happen
>> with
>>> some event on our servers.   I would require all webhook (callbacks) over
>>> SSL so that puts a requirement on the system I'm calling to support SSL,
>>> which I'm ok with.
>>> 
>>> How can the system I'm calling authenticate that the request is coming
>> from
>>> my servers?   Since I require SSL one option is client certificates.
>> I've
>>> not implemented client-side certs before, so not sure what is involved.
>>> But, it seems like the best option.
>>> 
>>> Our IP addresses may change or come from different machines so they
>> cannot
>>> be used.
>>> 
>>> I could use some shared secret and build a hash of the return data to
>> prove
>>> I know the secret.   But, that does not prove the request is coming from
>> my
>>> servers -- just that whoever sent the request knows the secret.
>>> 
>>> And by that logic if I know the shared secret, and I send over SSL then I
>>> could just send the shared secret back in the request without hashing any
>>> of the data and just the fact that I'm sending the shared secret should
>>> validate the request is coming from me (because only I know the secret).
>>> 
>>> I don't like overly complex hashing of parameters and all that when SSL
>>> really handles authentication, message signing, man-in-the-middle, and
>>> replay attack issues.
>>> 
>>> --
>>> Bill Moseley
>>> moseley at hank.org
>>> --
>>> 
>>> * * Please support the community that supports you.  * *
>>> http://evolt.org/help_support_evolt/
>>> 
>>> For unsubscribe and other options, including the Tip Harvester
>>> and archives of thelist go to: http://lists.evolt.org
>>> Workers of the Web, evolt !
>> --
>> 
>> * * Please support the community that supports you.  * *
>> http://evolt.org/help_support_evolt/
>> 
>> For unsubscribe and other options, including the Tip Harvester
>> and archives of thelist go to: http://lists.evolt.org
>> Workers of the Web, evolt !
>> 
> 
> 
> 
> -- 
> Bill Moseley
> moseley at hank.org
> -- 
> 
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
> 
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !