\r\n\r\n import base64\r\nimport hashlib\r\nimport hmac\r\nimport time\r\n\r\nMAX_CALLBACK_AGE_SECONDS = 300\r\n\r\n@router.post("\/sinch\/callbacks")\r\nasync def handle_callback(request: Request) -> Response:\r\n raw_body = await request.body()\r\n signature = request.headers.get("x-sinch-webhook-signature", "")\r\n nonce = request.headers.get("x-sinch-webhook-signature-nonce", "")\r\n timestamp = request.headers.get("x-sinch-webhook-signature-timestamp", "")\r\n\r\n try:\r\n age = abs(time.time() - int(timestamp))\r\n except ValueError:\r\n raise HTTPException(status_code=401, detail="Bad timestamp")\r\n if age > MAX_CALLBACK_AGE_SECONDS:\r\n raise HTTPException(status_code=401, detail="Stale callback")\r\n\r\n signed_data = raw_body + b"." + nonce.encode() + b"." + timestamp.encode()\r\n expected = base64.b64encode(\r\n hmac.new(\r\n settings.webhook_secret.encode(), signed_data, hashlib.sha256\r\n ).digest()\r\n ).decode()\r\n if not hmac.compare_digest(expected, signature):\r\n raise HTTPException(status_code=401, detail="Invalid signature")\r\n\r\n payload = json.loads(raw_body)\r\n if "message_delivery_report" in payload:\r\n await record_delivery(payload["message_delivery_report"])\r\n elif "message" in payload:\r\n await record_inbound_message(payload["message"])\r\n return Response(status_code=200)\r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\nIl y a quelques points \u00e0 bien ma\u00eetriser ici. La cha\u00eene sign\u00e9e est le corps brut, le nonce et l’horodatage\u00a0reli\u00e9s par des points, dans cet ordre, et le condens\u00e9 est en base64 plut\u00f4t qu’en hexad\u00e9cimal. Calculez-le sur les octets\u00a0bruts, et non sur un dictionnaire res\u00e9rialis\u00e9, sinon il ne correspondra jamais. La cl\u00e9 correspond au secret que vous avez d\u00e9fini lors de la cr\u00e9ation de votre\u00a0webhook, et x-sinch-webhook-signature-algorithm<\/code> vous indique l’algorithme utilis\u00e9\u00a0(HmacSHA256<\/code> aujourd’hui).<\/p>\n\n\n\nUne signature valide \u00e0 elle seule ne vous garantit pas que la requ\u00eate est r\u00e9cente. Toute personne qui capture un rappel\u00a0sign\u00e9 peut l’envoyer \u00e0 nouveau et le HMAC sera toujours valide. C’est pr\u00e9cis\u00e9ment la fonction de l’horodatage et du nonce\u00a0: Sinch d\u00e9crit le nonce comme \u00e9tant unique par rappel pour cette raison exacte. La fen\u00eatre de\u00a0cinq minutes ci-dessus est mon propre choix, et non une valeur document\u00e9e. Il s’agit de la solution de facilit\u00e9. Si vous\u00a0avez besoin d’un traitement strict \u00e0 usage unique, mettez en cache les nonces que vous avez d\u00e9j\u00e0 accept\u00e9s pendant la dur\u00e9e de cette\u00a0fen\u00eatre et rejetez les r\u00e9p\u00e9titions. La gestion idempotente est \u00e9galement recommand\u00e9e, car Sinch effectue de nouvelles tentatives avec\u00a0un d\u00e9lai de r\u00e9tablissement exponentiel et vous verrez l\u00e9gitimement le m\u00eame accus\u00e9 de r\u00e9ception deux fois. Toutefois, l’idempotence ne constitue pas\u00a0une protection contre la relecture\u00a0: elle emp\u00eache un rappel rejou\u00e9 de corrompre votre \u00e9tat sans jamais vous indiquer\u00a0qu’il a \u00e9t\u00e9 rejou\u00e9.<\/p>\n\n\n\n
Ajout du RCS<\/h2>\n\n\n\n Le chemin d’envoi \u00e9tant d\u00e9j\u00e0 ind\u00e9pendant du canal, le RCS est un type de message et une propri\u00e9t\u00e9 de canal\u00a0:<\/p>\n\n\n
\r\n\r\n
Mettez \u00e0 niveau le rappel vers une rich card RCS avec l’exp\u00e9diteur v\u00e9rifi\u00e9 RockBank, un r\u00e9capitulatif de paiement et un bouton \u00ab\u00a0Payer maintenant\u00a0\u00bb qui ouvre notre page de paiement h\u00e9berg\u00e9e. Conservez le repli sur le SMS pour les appareils qui ne prennent pas en charge le RCS.<\/p><\/div>\r\n <\/div>\r\n\n\n\n
La carte est un card_message<\/code> avec un choix url_message<\/code> dessus, transmis au m\u00eame _send<\/code> qu’auparavant\u00a0:<\/p>\n\n\n \r\n
\r\n\r\n \r\n \r\n \r\n \r\n Shell <\/button>\r\n <\/li>\r\n\r\n \r\n \r\n <\/ul>\r\n \r\n\r\n \r\n
\r\n
\r\n
\r\n
\r\n <\/svg>\r\n <\/svg>\r\n <\/button>\r\n <\/div>\r\n \r\n \r\n\r\n async def send_reminder_card( \r\n self, \r\n to: str, \r\n due_date: date, \r\n amount: Decimal, \r\n account_last4: str, \r\n payment_url: str, \r\n ) -> dict[str, Any]: \r\n card: dict[str, Any] = { \r\n "title": f"Payment due {due_date:%d %b}", \r\n "description": f"Amount: ${amount:,.2f}. Account ending {account_last4}.", \r\n "choices": [ \r\n {"url_message": {"title": "Pay now", "url": payment_url}} \r\n ], \r\n } \r\n return await self._send( \r\n to, \r\n {"card_message": card}, \r\n channel_properties={"RCS_WEBVIEW_MODE": "TALL"}, \r\n ) \r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\nchannel_properties<\/code> est une structure plate unique, de sorte que la cl\u00e9 RCS et le SMS_SENDER<\/code> dont le repli a besoin finissent\u00a0dans le m\u00eame dictionnaire. C’est en raison de cette fusion que _send<\/code> prend les propri\u00e9t\u00e9s comme argument au lieu de\u00a0les construire en ligne. RCS_WEBVIEW_MODE<\/code> contr\u00f4le la taille de l’\u00e9cran que la page de paiement occupe \u00e0 son\u00a0ouverture\u00a0: FULL<\/code>, HALF<\/code> ou TALL<\/code>.<\/p>\n\n\n\nDeux d\u00e9tails concernant le RCS sur lesquels il est facile de se tromper\u00a0:<\/p>\n\n\n\n
Le RCS ne traite pas le paiement.<\/strong> Le bouton \u00ab\u00a0Payer maintenant\u00a0\u00bb est une action d’URL. Il ouvre votre page de paiement h\u00e9berg\u00e9e\u00a0dans une webview par-dessus la discussion, la personne y effectue son paiement, et le contr\u00f4le revient \u00e0 la\u00a0conversation. Ce que le RCS vous apporte, c’est l’exp\u00e9diteur v\u00e9rifi\u00e9, la carte de marque et une personne qui ne\u00a0quitte jamais son application de messagerie. Le paiement transite toujours par votre fournisseur de paiement.<\/p>\n\n\n\nLes \u00e9checs de repli arrivent tardivement.<\/strong> Chaque canal que vous nommez dans channel_priority_order<\/code> doit \u00eatre\u00a0configur\u00e9 sur l’application, sinon la demande est purement et simplement rejet\u00e9e. C’est le cas le plus facile \u00e0 d\u00e9boguer. Le\u00a0cas le plus difficile concerne un canal configur\u00e9 qui ne parvient pas \u00e0 livrer\u00a0: messages:send<\/code> renvoie le code 200, et le\u00a0r\u00e9sultat s’affiche plus tard sous la forme d’un rappel MESSAGE_DELIVERY<\/code>, o\u00f9 SWITCHING_CHANNEL<\/code> marque le moment\u00a0o\u00f9 le repli s’est d\u00e9clench\u00e9. Une raison suppl\u00e9mentaire de configurer correctement les d\u00e9clencheurs de webhook avant de s’appuyer sur le chemin\u00a0de repli.<\/p>\n\n\n\nVoix, v\u00e9rification et email<\/h2>\n\n\n\n Les quatre autres \u00e9l\u00e9ments ont n\u00e9cessit\u00e9 un prompt chacun.<\/p>\n\n\n\n
Voix.<\/strong> Si le rappel reste sans r\u00e9ponse et que le paiement est toujours en attente, RockBank appelle. Une\u00a0diffusion par synth\u00e8se vocale ne n\u00e9cessite aucun serveur de flux d’appels, juste une requ\u00eate POST vers l’API vocale\u00a0:<\/p>\n\n\n \r\n\r\n
Ajoutez un rappel vocal pour les paiements qui sont toujours en attente deux jours apr\u00e8s l’envoi du message. Utilisez une diffusion par synth\u00e8se vocale via l’API vocale de Sinch avec nos identifiants d’application vocale, et d\u00e9finissez l’identifiant de l’appelant sur notre num\u00e9ro enregistr\u00e9.<\/p><\/div>\r\n <\/div>\r\n\n\n
\r\n
\r\n\r\n \r\n \r\n \r\n \r\n Shell <\/button>\r\n <\/li>\r\n\r\n \r\n \r\n <\/ul>\r\n \r\n\r\n \r\n
\r\n
\r\n
\r\n
\r\n <\/svg>\r\n <\/svg>\r\n <\/button>\r\n <\/div>\r\n \r\n \r\n\r\n async def place_reminder_call(self, to: str, message: str) -> dict[str, Any]:\r\n """Place a text-to-speech reminder call via the Voice API."""\r\n tts: dict[str, Any] = {\r\n "destination": {"type": "number", "endpoint": to},\r\n "cli": self.caller_id,\r\n "locale": "en-US",\r\n "text": message,\r\n }\r\n response = await self.client.post(\r\n "\/calling\/v1\/callouts",\r\n auth=(self.voice_app_key, self.voice_app_secret),\r\n json={"method": "ttsCallout", "ttsCallout": tts},\r\n )\r\n if response.is_error:\r\n raise SinchClientError(\r\n f"Voice callout failed ({response.status_code}): {response.text}"\r\n )\r\n return response.json()\r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\nNotez la diff\u00e9rence d’authentification\u00a0: la voix utilise une cl\u00e9 et un secret d’application, et non les\u00a0identifiants au niveau du projet qu’utilise l’API de conversation. Produit diff\u00e9rent, sch\u00e9ma d’authentification diff\u00e9rent, et les Skills\u00a0couvrent les deux. Le prompt n’a donc eu besoin d’expliquer ni l’un ni l’autre.<\/p>\n\n\n\n
La destination<\/code> d’un appel t\u00e9l\u00e9phonique est {\"type\": \"number\", \"endpoint\": \"+46...\"}<\/code> en E.164, et la\u00a0r\u00e9ponse vous donne un callId<\/code>. La r\u00e9f\u00e9rence de l’API indique que le param\u00e8tre cli<\/code> est facultatif, mais configurez-le tout de m\u00eame sur un num\u00e9ro\u00a0v\u00e9rifi\u00e9 ou attribu\u00e9 depuis votre tableau de bord\u00a0: sans un identifiant d’appelant utilisable, vous risquez de recevoir un ID d’appel\u00a0pour un appel qui n’atteint jamais le t\u00e9l\u00e9phone.<\/p>\n\n\n\nV\u00e9rification.<\/strong> Un mot de passe \u00e0 usage unique avant que la page de paiement n’accepte quoi que ce soit\u00a0:<\/p>\n\n\n \r\n\r\n
Avant que la page de paiement n’accepte quoi que ce soit, v\u00e9rifiez l’identit\u00e9 de la personne avec un mot de passe \u00e0 usage unique par SMS via l’API de v\u00e9rification de Sinch. Exposez la m\u00e9thode pour que nous puissions la changer \u00e0 chaque requ\u00eate.<\/p><\/div>\r\n <\/div>\r\n\n\n
\r\n
\r\n\r\n \r\n \r\n \r\n \r\n Shell <\/button>\r\n <\/li>\r\n\r\n \r\n \r\n <\/ul>\r\n \r\n\r\n \r\n
\r\n
\r\n
\r\n
\r\n <\/svg>\r\n <\/svg>\r\n <\/button>\r\n <\/div>\r\n \r\n \r\n\r\n async def start(self, phone: str, method: str = "sms") -> dict[str, Any]:\r\n response = await self.client.post(\r\n "\/verification\/v1\/verifications",\r\n auth=self._verification_auth,\r\n json={"identity": {"type": "number", "endpoint": phone}, "method": method},\r\n )\r\n ...\r\n\r\nasync def verify(self, reference: str, code: str) -> dict[str, Any]:\r\n path = f"\/verification\/v1\/verifications\/id\/{quote(reference, safe='')}"\r\n response = await self.client.put(\r\n path,\r\n auth=self._verification_auth,\r\n json={"method": "sms", "sms": {"code": code}},\r\n )\r\n ...\r\n <\/code>\r\n <\/pre>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n\n\n\n_verification_auth<\/code> repr\u00e9sente un troisi\u00e8me ensemble d’identifiants\u00a0: la v\u00e9rification s’authentifie avec la cl\u00e9 et le\u00a0secret de sa propre application dans le tableau de bord. Il ne s’agit donc ni des cl\u00e9s au niveau du projet qu’utilise l’API de conversation, ni de celles de l’application vocale.<\/p>\n\n\n\nstart<\/code> renvoie un id<\/code>, et c’est par rapport \u00e0 celui-ci que vous signalez le code. Les valeurs de la m\u00e9thode sont la partie\u00a0qu’il convient de conna\u00eetre\u00a0: sms<\/code> pour un mot de passe par message, callout<\/code> pour une lecture lors d’un appel t\u00e9l\u00e9phonique, auxquels s’ajoutent\u00a0flashcall<\/code>, seamless<\/code> et whatsapp<\/code>. Le corps du rapport est index\u00e9 par la m\u00eame m\u00e9thode, donc\u00a0{\"method\": \"sms\", \"sms\": {\"code\": \"1234\"}}<\/code> pour le message et\u00a0{\"method\": \"callout\", \"callout\": {\"code\": \"1234\"}}<\/code> pour l’appel.<\/p>\n\n\n\nLes v\u00e9rifications expirent au bout de quelques minutes. Par cons\u00e9quent, traitez une erreur 400 lors du signalement comme un appel \u00e0 \u00ab\u00a0en d\u00e9marrer une nouvelle\u00a0\u00bb plut\u00f4t que\u00a0comme une tentative \u00e9chou\u00e9e. Basculer une personne vers