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

[GOWS 2026.8.1] Passkey assertion accepted (201), but session stays PASSKEY_REQUIRED

Aperta
  • Qualcosa non va?
#2,227 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
43/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go, typescript
Ambito
backend-api-design

Direzione di ricerca

Start by tracing the GOWS passkey endpoint and session status handling around SendPasskeyResponse(), then inspect the whatsmeow fork’s handling of PairPasskeyConfirmation and crsc_continuation. Reproduce with the listed GOWS version and sanitized logs to determine whether the IQ result arrives without a continuation event. Done means the session progresses, exposes a confirmation step, or reports an actionable error after an accepted assertion.

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

Descrizione

engine:GOWS

Summary

With WAHA GOWS 2026.8.1, the WebAuthn assertion is successfully generated and accepted by the passkey endpoint, but the session never receives the expected continuation event. It remains in PASSKEY_REQUIRED until the pairing attempt expires or is stopped.

This is the post-assertion step described in tulir/whatsmeow#1186: after SendPasskeyResponse(), the client should receive PairPasskeyConfirmation (or proceed to successful pairing). Neither happens.

Environment

  • WAHA image: devlikeapro/waha:gows-2026.8.1
  • Engine: GOWS
  • GOWS version: v1.0.45
  • whatsmeow fork revision used by GOWS: devlikeapro/whatsmeow@78592f479441
  • Primary account: WhatsApp Business on iPhone
  • WebAuthn handoff: official WAHA Chromium extension on desktop Chrome/macOS
  • Pairing method: QR code

Reproduction

  1. Create and start a fresh GOWS session.
  2. Scan the QR code from WhatsApp Business on the iPhone.
  3. Session moves to PASSKEY_REQUIRED.
  4. Fetch the challenge with:
    GET /api/{session}/auth/passkey/challenge
  5. Pass the challenge unchanged to the official WAHA extension.
  6. Approve the cross-device passkey request on the iPhone.
  7. Submit the returned credential.toJSON() unchanged to:
    POST /api/{session}/auth/passkey
  8. The endpoint returns HTTP 201.
  9. Poll the live session status.

Observed result

  • The assertion is structurally valid:
    • type = webauthn.get
    • origin is https://web.whatsapp.com
    • authenticator RP ID hash matches whatsapp.com
    • user verification is present
    • authenticator attachment is cross-platform, consistent with the iPhone handoff
  • POST /api/{session}/auth/passkey returns 201.
  • The session stays in PASSKEY_REQUIRED for more than 110 seconds.
  • No PASSKEY_CONFIRMATION_REQUIRED status is emitted.
  • No confirmation code becomes available.
  • No WORKING status is reached.
  • No passkey error is surfaced.
  • The session is not stopped or restarted while waiting.

The flow has been reproduced on repeated fresh attempts.

Expected result

After the assertion is accepted, the session should either:

  1. transition directly to WORKING; or
  2. emit PASSKEY_CONFIRMATION_REQUIRED, expose the confirmation code, and allow POST /api/{session}/auth/passkey/confirm; or
  3. surface a protocol/passkey error instead of remaining silently blocked.

Similar report

evolution-foundation/evolution-go#107 reports the same behavior for a WhatsApp Business account: a correct WebAuthn assertion is submitted, the socket stays alive, but WhatsApp never sends PairPasskeyConfirmation.

Questions

  1. Is this silent post-assertion state known for some WhatsApp Business accounts?
  2. Does GOWS log or expose whether SendPasskeyResponse() received the expected IQ result but never received crsc_continuation?
  3. Is an additional handoff/continuation step required for these accounts?
  4. Which debug logging can we enable to provide a sanitized wire-level trace?
  5. Should this be escalated upstream to whatsmeow, or could it be specific to the devlikeapro fork/GOWS integration?

We can provide sanitized timestamps and debug logs, but will not publish the raw challenge or authenticator assertion.

Lingua principale
TypeScript
Stelle
7.6k
Fork
1.8k
Merge medio
2g 21h
PR unite (30g)
7

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 devlikeapro/waha

Tutte le issue di devlikeapro/waha

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.