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

Opening RTL causes CLN Application CSRF failure and misleading password prompt

Chiusa
  • Qualcosa non va?
#165 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
authentication, security

Direzione di ricerca

Inizia dalla configurazione CSRF di Axios e dal punto di ingresso RootService.getAuthStatus(), quindi riproduci con RTL il flusso del browser con lo stesso hostname e porte diverse. Traccia come il cookie XSRF-TOKEN raggiunge /v1/auth/isauthenticated/ e come il suo errore viene convertito nello stato della password. Il lavoro è completato quando RTL non invalida più l’autenticazione di CLN Application e gli errori CSRF o di rete non vengono mostrati come errori della password.

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

Descrizione

Summary

When CLN Application and Ride The Lightning (RTL) are served from the same hostname on different ports, opening RTL can cause CLN Application to fail its next authentication-status request with 403 Invalid CSRF token. Form tempered. CLN Application then displays its password dialog even when APP_SINGLE_SIGN_ON=true and the Umbrel session remains valid.

Browser cookies are scoped by hostname and path, not port. RTL writes a generic XSRF-TOKEN cookie at Path=/ on the shared hostname. Axios in CLN Application can consume that cookie for its XSRF header instead of the token CLN Application fetched from /v1/shared/csrf/.

Environment

  • Umbrel / umbrelOS
  • CLN Application image: ghcr.io/elementsproject/cln-application:26.04
  • CLN Application URL: http://<host>:2103/cln
  • APP_SINGLE_SIGN_ON=true
  • RTL URL: http://<host>:3100/rtl
  • Reproduced with RTL v0.15.8
  • Reviewed RTL v0.15.12 source: it still uses the generic XSRF-TOKEN cookie at Path=/
  • Both apps use the same hostname and different ports

Steps to reproduce

  1. Log in to Umbrel normally.
  2. Open CLN Application and confirm it authenticates through SSO and displays node data without a password prompt.
  3. Open RTL on the same hostname in the same browser profile.
  4. Return to or reload CLN Application.

Actual behavior

CLN Application sends POST /v1/auth/isauthenticated/, receives HTTP 403, zeroes the displayed node data, and opens the password dialog.

Browser console:

Failed to load resource: the server responded with a status of 403 (Forbidden)
HTTP Request failed for post /auth/isauthenticated ... Invalid CSRF token. Form tempered.
Auth Status failed: Invalid CSRF token. Form tempered.

CLN Application server log at the same timestamps:

Invalid CSRF token. Form tempered.

This is misleading because the password is not wrong and SSO is still valid. lightningd remains healthy.

Confirmed recovery

Expiring only the XSRF-TOKEN cookie for the shared hostname at Path=/, then reloading CLN Application, immediately removes the password dialog and restores authenticated node data. Neither CLN Application nor lightningd needs to be restarted.

A direct HTTP test that shared only the _csrf cookie did not reproduce the failure. The real browser flow did reproduce it, which points specifically to Axios automatically reading RTL's visible XSRF-TOKEN cookie.

Relevant CLN Application behavior

CLN Application explicitly fetches a CSRF token from /v1/shared/csrf/ and assigns it to Axios's X-XSRF-TOKEN default header. However, Axios also has conventional XSRF-TOKEN cookie handling.

Separately, RootService.getAuthStatus() catches any request error and returns a state equivalent to unauthenticated with a valid password. Startup then opens the password modal, masking the underlying CSRF error.

Expected behavior

  • Cookies created by another same-host application must not invalidate CLN Application requests.
  • A CSRF/network error from /auth/isauthenticated must not be presented as a password failure.
  • With APP_SINGLE_SIGN_ON=true, this failure should provide a recoverable error state rather than a password prompt.

Suggested fixes

  1. Give CLN Application unique XSRF cookie/header names, or disable Axios automatic XSRF-TOKEN cookie consumption because CLN Application already fetches and sets its CSRF token explicitly.
  2. Consider scoping the CLN CSRF cookie to an application-specific path where deployment routing permits it.
  3. Preserve the actual authentication-status error in getAuthStatus() and do not convert every exception into the password-login state.

I can provide additional sanitized network traces if needed.

Lingua principale
TypeScript
Stelle
52
Fork
14
Merge medio
3m
PR unite (30g)
1

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

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 ElementsProject/cln-application

Tutte le issue di ElementsProject/cln-application

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.