Login form variants

Each variant is a different shape of login form. They all submit synthetic credentials to a sink that accepts anything, then behaves exactly like a real login would: it sets a session cookie (HttpOnly __session + JS-readable bb_session_js companion + x-auth-token header) and 302-redirects to /. There is no diagnostic echo of what you submitted — that would change the shape the intermediary sees. To verify your form data reached the server, check your browser's network tab.

The test point is whether the intermediary (a) lets the page load, (b) lets the form submit, and (c) passes the auth response (Set-Cookie + redirect) back to the client.

• Standard POST with type=password
  Canonical credential-stuffing shape: <form method="post"> with input[type="password"]. Expected to trip a password-typing defense if the intermediary has one.
• POST with type=text masquerading as a password
  Same form, but the password field uses type="text" + autocomplete="current-password". Tests whether a password-typing block triggers on the input type attribute or on something else (field name, autocomplete, behavior).
• POST with renamed fields
  Fields named user_credential and secret_key instead of login/password. Tests whether the intermediary keys on field-name heuristics.
• GET-method login
  Form with method="get" — puts the synthetic creds in the URL query string. Tests whether any POST-block at the intermediary is method-specific or treats GET creds the same way.
• Multi-step (email → password page)
  Two-page flow like Amazon / many SSO providers. Tests behavior when the form interaction spans navigations.
• XHR-based POST (no <form> element)
  No HTML form. Credentials posted via fetch() JSON body. Tests whether the POST-block / password-typing rules apply when there is no form context.

What each variant looks like to the intermediary

Typical things to look for:

• curl through an intermediary: whether POSTs are blocked at the intermediary tier (and if so, whether the block is method-specific so the GET variant passes through).
• Playwright through an automation tool: whether variants with input[type="password"] trip a password-typing block while non-password-typed fields fill normally, and whether the XHR variant bypasses any form-input controls entirely.