HTTP target (LiteSpeed WebAdmin) login loop: POST /login.php succeeds, follow-up GET /index.php de-authenticates session

[wm-ek]

Hi

Thanks for fixing #2048 !

We still have a reproducible login loop on the LiteSpeed HTTP target behind Warpgate.

Summary

When LiteSpeed WebAdmin is accessed through Warpgate, login enters a loop:

• POST /login.php appears successful (302)
• Follow-up navigation does not establish a stable authenticated session
• Client is redirected back to login, and session cookies are deleted

With RUST_LOG enabled, Warpgate logs show redirect/path anomalies during this flow, including:

• HTTP: Request without URI https://<public-gateway-domain>/
• HTTP: Remote redirect from "/login.php" to "/login.php"

This appears related to proxy redirect/URI handling and correlates with session non-persistence.

Environment

• Warpgate: v0.25.5
• Target app: LiteSpeed WebAdmin (https://<internal-target>:7080)
• Accessed via Warpgate external endpoint: https://<public-gateway-domain>
• Browser: Chrome
• Relevant configuration:
  • target points to LiteSpeed HTTPS origin
  • external_host configured
  • target TLS verification disabled (tls.verify: false)

Expected behavior

After submitting valid credentials to /login.php, user should land on authenticated admin UI (e.g. /index.php) and remain logged in.

Actual behavior

Authentication loops:

1. POST /login.php returns 302
2. Redirect sequence occurs
3. Session does not persist
4. User is returned to login
5. Response sets deletion cookies (e.g. lsws_uid=deleted, lsws_pass=deleted, LSWSWEBUI=deleted)

New evidence from RUST_LOG (anonymized)

During reproduction, Warpgate logs include:

• HTTP: Request without URI https://<public-gateway-domain>/ ... status=302 ...
• HTTP: Remote redirect from "/login.php" to "/login.php" ...
• repeated redirect/connect cycles immediately after login attempt
• CookieHostMiddleware: No session cookie found in <n> cookie(s) appears in the same window

These lines occur around the login redirect flow and are consistent with proxy-side URI/redirect/session handling issues.

Additional code-level observations (from current main)

1) Session can be cleared on host authorization mismatch

In warpgate-protocol-http/src/common.rs (inject_request_authorization), host mismatch leads to:

session.clear();
session_auth = None;

If this is triggered during redirect follow-up requests, it would explain immediate de-authentication.

2) Cookie rewriting is applied on responses

In warpgate-protocol-http/src/proxy.rs (rewrite_response), Set-Cookie handling includes:

• forcing session expiry
• unsetting cookie domain

This may interact with redirect/path behavior and cookie scoping.

3) Forwarded headers are injected

Warpgate adds standard forwarding headers (X-Forwarded-*), so origin behavior may depend on those plus host/URI normalization.

Why this seems proxy-related (not credentials-related)

• Credentials are accepted initially (POST /login.php -> 302)
• Failure occurs on immediate redirect/navigation phase
• Logs show URI/redirect anomalies in that exact phase
• Session/cookie continuity breaks only after redirect chain

A) HTTP redirect/cookie timeline (sanitized)

[1] POST https://access.example.tld/login.php
    -> 302 Found
    -> Location: /index.php
    -> Set-Cookie: lsws_uid=<redacted>; Path=/; Secure; HttpOnly
    -> Set-Cookie: lsws_pass=<redacted>; Path=/; Secure; HttpOnly

[2] GET https://access.example.tld/index.php
    -> 302 Found
    -> Location: /login.php
    -> Set-Cookie: lsws_uid=deleted; Path=/; Expires=<...>
    -> Set-Cookie: lsws_pass=deleted; Path=/; Expires=<...>
    -> Set-Cookie: LSWSWEBUI=deleted; Path=/; Expires=<...>

[3] GET https://access.example.tld/login.php
    -> 200 OK (login form again)

B) Warpgate logs around failure window (sanitized)

<ts> INFO  HTTP: Request without URI https://access.example.tld/ ... status=302 ...
<ts> DEBUG HTTP: Remote redirect from "/login.php" to "/login.php" ...
<ts> DEBUG CookieHostMiddleware: No session cookie found in 1 cookie(s)
<ts> INFO  HTTP: /login.php ... status=302 ...
<ts> INFO  HTTP: /index.php ... status=302 ...