Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

webhook: case-sensitive signature-header lookup 500s behind ASGI; strict encrypted pre-verify deadlocks url_verification handshake

Aperta
  • Qualcosa non va?
#12 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
api, backend

Direzione di ricerca

Individua _verify_sign e il ramo url_verification, quindi riproduci i casi segnalati nella suite di test con header in minuscolo e payload di handshake crittografati e non firmati. Il lavoro è completato quando le richieste ASGI legittimamente firmate non restituiscono più 500 e le richieste url_verification in chiaro o crittografate convalidano il proprio token e completano la challenge.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Two concrete webhook bugs observed on 1.2.0 behind ASGI servers

Related to #11 but these are straight bugs rather than hardening gaps, so filing separately.

1. _verify_sign header lookup is case-sensitive → TypeError/500 behind ASGI

Starlette/FastAPI (per the ASGI spec) hand the application lowercase header names. _verify_sign looks up X-Lark-Request-Timestamp / X-Lark-Request-Nonce / X-Lark-Signature case-sensitively, gets None, and then None + None + encrypt_key raises TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType' → every legitimately signed request 500s.

Reproduced with the real SDK (no mocks) in our test suite: passing lowercase headers reproduces the 500; re-canonicalizing the three header names before calling the SDK makes the same request pass. Suggested fix: case-insensitive header lookup (e.g. normalize to lower on both sides).

2. strict-mode encrypted pre-verification rejects Feishu's own url_verification handshake

The "save request URL" challenge that the Feishu console sends during first-time webhook configuration is not signed (platform behavior). With an encrypt key configured, the strict-mode encrypted pre-verification rejects the encrypted-but-unsigned handshake before the url_verification branch is reached — so an integrator using strict mode + encryption can never complete the console's URL-verification step. First-time webhook setup deadlocks.

Our workaround is to detect the handshake (plaintext and encrypted forms, both the legacy flat body and the v2/p2 schema), validate verification_token, and answer the challenge ourselves without forwarding it to the SDK. Suggested fix: exempt url_verification from the signature requirement (it carries the verification token as its own proof), or provide a documented hook for it.

Both behaviors reproduced on lark-channel-sdk==1.2.0; happy to share the test cases.

Lingua principale
Python
Stelle
17
Fork
8
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di larksuite/channel-sdk-python

Tutte le issue di larksuite/channel-sdk-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.