[DesarrolloAntonio]

AdventureLog server v0.13.1 removed the middleware that read X-Session-Token and the CSRF exemptions for mobile login. Against it the app could not sign in (login answered 403 "CSRF cookie not set") and every other request ran anonymous.

Changes

• KtorAdventureLogNetwork: the existing HttpSend interceptor adds what a Django session needs to every request bound for the signed-in server: Cookie: sessionid=…; csrftoken=…, X-CSRFToken and a same-origin Referer. The CSRF token is generated by the app (32 × [A-Za-z0-9]); Django's double-submit check accepts it, so nothing new is stored and existing sessions keep working after the update. X-Session-Token is still sent: servers before 0.13.1 read it, and the 401 detector uses it as a marker.
• The session id is taken from the request itself, not from the network's field, so the background sign-out still sends it after clearSession().
• Image client (ImageLoaderModule) sends the sessionid cookie too. Without it, photos of private places render blank.
• scripts/qa/adapter.py authenticates the same way.
• Also includes scripts/release/create_signing_secrets.sh and the signing/ gitignore line, so the local keystore folder can't be committed from this branch.

Tests

• DjangoSessionHeadersTest (4 tests): an authenticated write, login, sign-out after the session is cleared, no cookie sent to another host. Each one was seen red with the change disabled.
• ./gradlew allTests: 774 tests, 0 failures (iOS compile included).

Manual validation — Pixel 6a against the NAS on v0.13.1

• Debug: an existing session survives the update. From the app: create, edit and delete a place; photo upload, and the photo renders on a private place; add and delete a visit; create, rename and delete a collection; note; checklist and ticking an item; add a place to a collection; mark and unmark a region; collection PDF download; sign-out; sign-in.
• R8 release (signed with a throwaway key): sign-in, Home, Places, Collections, Map, World, create and delete a place, mark and unmark a region. 0 crashes, 0 ANR.
• Each step was checked against the server API. Test data was deleted afterwards.

Not driven: iOS (the Darwin engine has its own cookie store and may treat a manual Cookie header differently), transport, lodging, categories, sharing with other users.

Note: the v0.0.9-alpha release published today was built before this fix, so it can't sign in to 0.13.1 servers.

Update: upstream's all-in-one install

Upstream's default install since 0.13 is one container where /api and /auth go through the SvelteKit frontend. Its proxy (django-proxy.ts) drops every Set-Cookie, adds its own CSRF token and redirects URLs ending in / with a 308, so the app could not sign in there (403). da8a97ab:

• Login goes through allauth's app client (/auth/app/v1/auth/login), which returns the session in the body. It is a Django session key, sent as the sessionid cookie. The app route has existed since server v0.8.
• /csrf/ is probed once per server: JSON means Django directly, HTML means the proxy.
• Behind the proxy, the app sends only the session cookie and Origin (SvelteKit refuses form posts without it, so photo uploads failed), and no trailing slash.
• Sign-out stays on the browser route: the app client's DELETE answers 401 and leaves the session alive (measured on both installs).

Validated on the Pixel 6a against a public all-in-one 0.13.1 (adventurelog.desarrollodroide.es): sign-in, Home, create a place, photo upload (rendered on a private place), collection, note, mark and unmark a region, deletes. And against the NAS (separate images): the existing session keeps working. 3 more tests (each seen red); allTests 780/0 before the Origin commit, network tests green after it.

🤖 Generated with Claude Code