[Bug]: Android sideload Basic Auth returns 401 for valid Dashboard credentials

[chipsfromhell]

Affected area

Android app

What happened?

Observed: Hermes-Relay Android sideload v1.15.1 returns HTTP 401 with {"detail":"Invalid credentials"} when signing into a self-hosted Hermes Dashboard using its native Basic Auth provider.

The exact same Dashboard URL, username, and clipboard password authenticate successfully in Android Chrome. A direct scripted request to the same password-login endpoint also returns HTTP 200 and sets the expected session cookies.

Expected: The sideload app should authenticate with the same valid Basic Auth credentials accepted by the Dashboard web login and direct API request.

Reproduction steps

1. Run a self-hosted Hermes Dashboard with authentication enabled and the native Basic Auth provider configured.
2. Verify the Dashboard login works in Android Chrome.
3. In Hermes-Relay Android sideload v1.15.1, configure the same private-LAN Dashboard URL.
4. Enter the same username and paste the same password.
5. Submit the Dashboard sign-in form.
6. Observe Dashboard sign-in failed - HTTP 401: {"detail":"Invalid credentials"}.

The failure reproduces after force-closing and reopening the app. The Google Play and sideload packages are both installed, but they have distinct application IDs and isolated app data.

Environment

• Hermes-Relay version/tag: android-v1.15.1
• Install surface: official sideload APK
• Android package: com.axiomlabs.hermesrelay.sideload
• Android device and OS: not captured
• hermes-agent version: 0.21.0
• Connection mode: private LAN over HTTP
• Dashboard auth provider: native Basic Auth

Sanitized logs, screenshots, or traces

Dashboard sign-in failed - HTTP 401: {"detail":"Invalid credentials"}

Control checks against the same endpoint and credentials:
- Android Chrome Dashboard login: success
- Direct password-login API request: HTTP 200
- Session cookies returned by successful direct login:
  - hermes_session_at
  - hermes_session_rt
  - hermes_session_provider

Upstream or standard-path notes

The Android app connects directly to the Hermes Dashboard. A locally installed Relay plugin is present but is not involved in this password-login request. Browser and direct API controls against the same Dashboard succeed.

The private Dashboard disables native PKCE advertisement so Android uses the advertised Basic Auth flow. This affects auth-flow selection only. The server's Basic Auth credential itself is proven valid by both browser and direct API controls.

Checklist

• I searched existing issues first.
• I removed secrets, tokens, private infrastructure, and personal names.
• I included the affected version and install surface.

[hermes-relay-triage]

🤖 Hermes-Relay automated triage

Thanks for the detailed reproduction and the browser/API control checks! Android v1.15.1 and current dev both send the advertised Basic Auth flow to /auth/password-login with a cookie-only client, and the existing regression test confirms that route and session-cookie path for simple ASCII credentials. The app currently submits the username and password exactly as entered, so a hidden newline or other clipboard whitespace is one plausible difference from the browser/scripted requests, but that is not confirmed from the available evidence.

Could you try one controlled variation by typing both fields manually instead of pasting, and share the device model and Android version? A maintainer will follow up to confirm whether this is input normalization, a device-specific text-field behavior, or another request-level mismatch.

[chipsfromhell]

Controlled test result:

• Device: Samsung Galaxy M52 5G
• Android: 13
• Manually typing both the username and password in the sideload app succeeds.
• Pasting the same password into the sideload app consistently returns HTTP 401: {"detail":"Invalid credentials"}.
• That clipboard value authenticates successfully when pasted into Android Chrome against the same Dashboard URL, and the same stored credential succeeds through a direct API request.
• Clearing the app password field, pasting, then pressing Backspace once still returned 401.

This isolates the failure to the sideload app's pasted-input path or its handling of clipboard characters, rather than the server credential or Basic Auth endpoint. No credential contents are included here.