fix: el botón de borrar notificaciones fallaba con un 403 de CSRF #17
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "HBB/rocinante_android:fix/clear-notifications-csrf"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
El borrado de notificaciones nunca llegaba a ejecutarse en el servidor y la app
informaba de éxito igualmente, así que el fallo pasaba desapercibido.
Tres causas encadenadas:
NotificationsViewModelera el único punto de la app que hacía un POST con elBookWyrmApiinyectado por Hilt. Ese cliente no tiene CookieJar (fija la cabeceraCookiemanualmente e ignora losSet-Cookie), por lo que enviaba una cookiecsrftokenobsoleta y Django rechazaba el formulario con un 403. Ahora el POST usael cliente de sesión de
NetworkClient—el mismo que ya usan la respuesta apublicaciones y la actualización de progreso—, que la pestaña ya recibía como
parámetro pero no utilizaba.
Se enviaba como
csrfmiddlewaretokenel token enmascarado extraído del HTML enlugar del valor de la cookie
csrftoken. Se aplica el mismo criterio que en laactualización de progreso: se usa la cookie y el token del HTML queda de respaldo.
Aun con el POST correcto,
response.isSuccessfuldaba falso: la vista de BookWyrmborra y termina con
redirect("/notifications"), y el cliente de sesión no sigueredirecciones, así que la respuesta normal es un 302. Se acepta cualquier 3xx.
Además,
clearAllNotificationsinvocaba el mismo callback tanto al acabar bien como alfallar, de modo que siempre se mostraba «Notificaciones borradas». Ahora devuelve un
ClearResulty la interfaz muestra el error real. Se añaden trazas de logcat(
RocinanteNotif) solo en caso de fallo; no se registra ningún token.Verificado en un dispositivo real contra bookwyrm.social.
El borrado de notificaciones nunca llegaba a ejecutarse en el servidor y la app informaba de éxito igualmente, así que el fallo pasaba desapercibido. Tres causas encadenadas: 1. `NotificationsViewModel` era el único punto de la app que hacía un POST con el `BookWyrmApi` inyectado por Hilt. Ese cliente no tiene CookieJar (fija la cabecera `Cookie` manualmente e ignora los `Set-Cookie`), por lo que enviaba una cookie `csrftoken` obsoleta y Django rechazaba el formulario con un 403. Ahora el POST usa el cliente de sesión de `NetworkClient` —el mismo que ya usan la respuesta a publicaciones y la actualización de progreso—, que la pestaña ya recibía como parámetro pero no utilizaba. 2. Se enviaba como `csrfmiddlewaretoken` el token enmascarado extraído del HTML en lugar del valor de la cookie `csrftoken`. Se aplica el mismo criterio que en la actualización de progreso: se usa la cookie y el token del HTML queda de respaldo. 3. Aun con el POST correcto, `response.isSuccessful` daba falso: la vista de BookWyrm borra y termina con `redirect("/notifications")`, y el cliente de sesión no sigue redirecciones, así que la respuesta normal es un 302. Se acepta cualquier 3xx. Además, `clearAllNotifications` invocaba el mismo callback tanto al acabar bien como al fallar, de modo que siempre se mostraba «Notificaciones borradas». Ahora devuelve un `ClearResult` y la interfaz muestra el error real. Se añaden trazas de logcat (`RocinanteNotif`) solo en caso de fallo; no se registra ningún token. Verificado en un dispositivo real contra bookwyrm.social.Muchas gracias. Tenía esto pendiente y me has quitado un buen peso de encima.
Pull request closed