Si la cible d'un webhook est accessible au public, il faut s'assurer, pour les requêtes entrantes, qu'elles proviennent du système d'origine souhaité. L'origine d'un webhook peut être garantie à l'aide d'une clé secrète.
L'idée d'une clé secrète #
Pour créer un nouveau webhook, il suffit d'indiquer une URL quelconque. La clé secrète peut également rester vide. Toutefois, si votre URL cible est disponible publiquement, vous devez définir une clé secrète et valider cette valeur lors du traitement des webhooks. Dans le cas contraire, n'importe qui peut vous envoyer des demandes correspondantes à cette URL de webhook, qui seront ensuite traitées par vous. Sans la clé secrète, le système cible n'a aucun moyen fiable de savoir si l'événement provient réellement de SeaTable.
Si vous indiquez une clé secrète, le webhook dispose d'une clé supplémentaire. X-SeaTable-Signature-HeaderIl s'agit d'une clé secrète qui permet de garantir l'origine du webhook. Tant que quelqu'un d'autre ne connaît pas la clé secrète, il n'est pas en mesure de vous envoyer des événements par webhook et d'utiliser la clé correspondante. X-SeaTable-Signature-Header de produire.
Lorsqu'une clé secrète est définie, une requête de webhook ressemble par exemple à ceci :
-- HEADER --
Content-Type: application/json
Content-Length: 625
X-Seatable-Signature: sha256=598b55485e7875def064746867ff220e79d7c75512fdb931a39e313af5abfe60
Connection: keep-alive
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: python-requests/2.28.1
Host: example.com
-- CONTENT --
{
event:update
data: {
dtable_uuid: 6c17f178ee724c109c68ecee364027fc
row_id: Y_aYcE6wTo-IzGWb-oDmaQ
op_user: 92d8f9b243f8437db0131c2536398403@auth.local
op_type: create_row
op_time: 1677595743.088
table_id: 0000
table_name: Table1
row_name: ""
row_data: []
}
}
Le calcul de la clé secrète #
La clé secrète est un secret partagé entre SeaTable et le système récepteur. SeaTable utilise la clé secrète pour calculer une valeur de hachage à partir de l'événement. Le système récepteur peut utiliser la clé secrète pour calculer le contenu à partir de la valeur de hachage et le comparer au contenu réel. Si le contenu réel ne correspond pas au contenu calculé à partir du hachage, il ne faut pas traiter le webhook.
Validation de la signature #
Dans chaque langage de programmation, il devrait y avoir des fonctions correspondantes pour pouvoir valider une telle signature en conséquence. Cet article vous montre à quoi ressemblerait cette vérification en PHP.
Pour Python, un examen pourrait ressembler à ceci :
import hmac
from flask import Flask, request
app = Flask(__name__)
@app.route('/receive-seatable-webhook', methods=['POST'])
def receive-seatable_webhook():
secret = 'secret'
seatable_signature = request.headers.get('X-Seatable-Signature', '').replace('sha256=', '')
signature = hmac.new(
secret.encode('utf-8'), request.data, digestmod='sha256').hexdigest()
signature_compare = hmac.compare_digest(signature, seatable_signature)
if signature_compare:
# do something
pass
return {'success': signature_compare}
