Yuvomi Mobile Contributors
4b483c20e3
Reproduce browser-success/native-401 with unmodified upstream SESSION_SECURE=false behind HTTPS. Keep cookies in the existing HTTPS-only origin-bound encrypted jar regardless of the server Secure attribute; preserve TLS, redirect, expiry and origin protections. Distinguish credential/2FA rejection from missing/rejected session handoff and clear stale login errors on retry. Verify 13 JVM tests plus the 7-test real-server suite in both Secure/default-cookie modes, including bad-password then successful native login. Bump Android preview to 0.2.1/code 3; extend CI and document the defect without claiming access to the user's production server.
2.8 KiB
Android native login: 0.2.1 preview fix
Reproduced compatibility defect
The Android 0.2.0 native preview could show “Anmeldung oder Sitzung ist nicht mehr
gültig” even when the identical direct username/password login worked in the PWA.
Upstream defaults to SESSION_SECURE=false; an HTTPS reverse proxy does not by
itself change this cookie attribute. The old native jar rejected the session
cookie without Secure, so the successful login was followed by an unauthenticated
API request. This was an app compatibility defect, not evidence of a bad password.
Android 0.2.1 native preview (version code 3) keeps the cookie in its existing
HTTPS-only, origin/port-bound jar. It still never makes HTTP requests, follows
redirects or shares cookies with another server. System TLS validation,
AndroidKeyStore encryption and absolute expiry remain unchanged. The native client
does not depend on weakening the server or changing its configuration. For browser
security, server operators should still use SESSION_SECURE=true on HTTPS sites.
Error distinctions
- Rejected username/password: the server rejected
/auth/loginwith HTTP 401. - Invalid/expired second-factor step: the verification endpoint rejected the code or its pending session. Restart login if necessary.
- Login confirmed but no usable cookie: inspect server/reverse-proxy cookie configuration; no password-reset claim is made.
- Login confirmed but session rejected: inspect server/proxy session handling.
The app never displays raw cookie values, credentials or arbitrary server response bodies as diagnostics. A failed attempt's message is cleared after successful retry. If the updated app still fails, report the exact new message, app/server version, whether the direct browser password login works and whether 2FA is enabled. Do not send passwords, session cookies, recovery codes or authentication tokens.
Reproduction and regression evidence
python3 scripts/test-integration.py /path/to/pinned-upstream --android --cookie-without-secure
python3 scripts/test-integration.py /path/to/pinned-upstream --android
The first mode fails with the old native jar despite successful protocol-level browser login. After the fix, it passes native login, a wrong-password/correct-retry sequence, dashboard/recreation, task/note/shopping operations and logout. The normal Secure-cookie mode remains required too. These use synthetic temporary records and the unmodified pinned upstream, not the user's server or credentials.
Development APKs from different CI jobs can have different debug signing keys. If Android rejects an update as signature-incompatible, uninstall the old preview before installing the new one. This clears local app/session data and requires a fresh login; server household records are not deleted. Production signing remains paused and full native PWA parity is not implied by this fix.