SHA256
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.
52 lines
2.8 KiB
Markdown
52 lines
2.8 KiB
Markdown
# 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/login` with 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
|
|
|
|
```sh
|
|
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.
|