| Discussion Forum: Thread 219140 |
|
 |
| | | Author: | ignacioxd  | | Posted: | Apr 12, 2017 00:15 | | Subject: | API Push Notification Signatures | | Viewed: | 122 times | | Topic: | Suggestions | | Status: | Discarded | |
|
| The API currently allows registration of notification URLs that will get POST
data once some events are raised (orders, messages, feedback). This is great!
However, in order to implement this we need a server that accepts POST data publicly.
Right now there is no easy way to verify that this POST request is actually coming
from BrickLink.
While we can check the IP from which the request originated, I think a better
alternative would be for the push notification request to contain a signature
in the body. Perhaps the ConsumerSecret could be used to sign the request via
HMAC and include this signature as part of the request? Including an additional
attribute in the JSON object should not break existing implementations.
|
|
|
| | | | | |
| | | | | Author: | minithings4life | | Posted: | Apr 12, 2017 03:35 | | Subject: | Re: API Push Notification Signatures | | Viewed: | 36 times | | Topic: | Suggestions | |
|
| To ensure that the request is coming from Bricklink, just verify that the contents
in POST are the fields that you are expecting from Bricklink. Does it include
a valid Bricklink order number for example.
Then validate each piece of data, to ensure there is no SQL injections, or other
nasties.
|
|
| | | | | | | | | |
| | | | | | | Author: | ignacioxd | | Posted: | Apr 12, 2017 11:55 | | Subject: | Re: API Push Notification Signatures | | Viewed: | 32 times | | Topic: | Suggestions | |
|
| In Suggestions, Minifigforlife writes:
| | To ensure that the request is coming from Bricklink, just verify that the contents
in POST are the fields that you are expecting from Bricklink. Does it include
a valid Bricklink order number for example.
Then validate each piece of data, to ensure there is no SQL injections, or other
nasties.
|
Just because the payload is valid does not mean it comes from BrickLink though.
For example, let's say I know that a particular store receives push notifications
and that I know the address where the notifications are posted. If I place an
order in that store I also now also have a valid order number for that store.
I could then POST
{
"event_type":"Order",
"resource_id": KNOWN_ORDER_NUMBER,
"timestamp": SOME_TIMESTAMP
}
which is a valid payload for that store. Even if the order number is not valid,
someone handling this incoming push notification will most likely issue a call
to the BrickLink API to get more information on that supposedly new order only
to find out then that the order is invalid. If the order is valid, it could also
result in duplicate records on the client (if coded poorly).
In any case, this causes unnecessary load to the BrickLink API that could be
avoided if the client could simply verify a signature.
|
|
|
| | | | | |
| | | | | Author: | ignacioxd | | Posted: | Apr 16, 2017 13:21 | | Subject: | Re: API Push Notification Signatures | | Viewed: | 25 times | | Topic: | Suggestions | |
|
| I see that this suggestion is now marked as discarded, yet no comment was provided
as to why. It would be nice to hear from BrickLink their reasoning behind their
decisions.
|
|
|
|
|
|
USA, North Carolina
United Kingdom, England