skip to content

When would you pick the authhelper add-on's browser-based login over a core form-based one for a CI scan?

level: seniorimportance: should knowfreq 50%

answer

  1. describe the request, or drive the page
  2. one needs nothing, one needs a browser
  3. the add-on infers what it was not told
  4. field detection is a heuristic cascade

basics

~20 s

When replay cannot reproduce the login: the request is built or signed by page JavaScript, or the flow has steps one request cannot express. Otherwise prefer the core form method - cheaper, deterministic, and needing no browser.

solid answer

~50 s

Core's `form` and `json` methods **replay a request you described**: you supply the URL, the body and the credential placeholders, and the tool sends two HTTP requests. The `authhelper` add-on's `browser` method **drives a real browser** through the `selenium` add-on, routes its traffic through a local server, and then identifies the authentication request from what it saw. Prefer replay by default - it is deterministic, costs nothing per attempt, runs on an image with no browser, and when it is wrong you can read the exact bytes it sent. Move to the browser method when replay genuinely cannot reproduce the login. Pay attention to what it is guessing at: it locates the password field by input type and then by id or name, and the username field by a short cascade ending in indicator words, so an unusual login page silently fills the wrong box.

go deeper

for a junior

Know the two shapes: one replays a request you wrote down, the other drives a real browser and works the request out for itself.

for a middle

Explain what the browser method is inferring - which field is the password, which is the username - and that those are heuristics over the displayed inputs rather than configuration.

for a senior

Argue the trade with costs attached: wall-clock time, a browser dependency in the image, and flakiness, against a login that replay genuinely cannot reproduce.

for a principal

The standardisation call is which method is the default for the fleet and what evidence a pipeline must produce that its login worked, so the choice is auditable rather than per-team folklore.

## Two fundamentally different strategies Every login method this tool offers is one of two shapes. **Replay a request you described.** Core's form-based and JSON-based methods send a login request you configured: a URL, a body, and two credential placeholders that are substituted per user. You supply the knowledge of what a successful login looks like; the tool supplies the repetition. **Drive a browser and watch.** The `authhelper` add-on's browser-based method obtains a WebDriver through the `selenium` add-on, starts a local server so the browser's traffic passes through it, loads the login page, fills the fields, submits, and then **identifies the authentication request from the traffic it just saw**. You supply a login page URL; the tool works out the rest. The client-script method sits between them: it extends core's script method, but its script drives a browser rather than building an HTTP message. Summarised: - **replay** - you own the knowledge, the tool owns the repetition; - **browser** - the tool owns the knowledge, and you own a browser dependency; - **client script** - you own both, which is the most work and the most control. ## What the browser method is guessing at It is worth being concrete, because "it just works" is how teams get surprised. The field detection is a **heuristic cascade**: - the password field is the first displayed input whose type is `password`, and failing that one whose id or name contains the word; - the username field is the only displayed input if there is exactly one, failing that a displayed input of type `text` or `email`, failing that one whose id or name contains one of a short list of indicator words in a handful of European languages. That is robust against a page being rendered by JavaScript, and fragile against a login that does not look like a login - a passwordless flow, a username-only first step, an unlabelled field, a locale the indicator list does not cover. When it guesses wrong it does not throw; it fills the wrong box or nothing at all. ## The comparison that matters for a pipeline | | replayed request (core `form` / `json`) | browser-driven (`authhelper`) | |---|---|---| | what you configure | the login request itself | the login page URL | | what runs it | two HTTP requests | a real browser session | | runner needs | nothing extra | `selenium`, and a browser installed | | handles JS-built or signed logins | no | yes | | handles multi-step or redirect-heavy flows | poorly | better | | determinism | high - same bytes each time | lower - a real page, a real browser | | cost per attempt | negligible | seconds, plus memory | | failure mode | posts the wrong thing silently | fills the wrong field silently | ## How to choose 1. **Start with the replayed request** when the login is a plain form or a JSON API call. It is cheaper, it is deterministic, it runs anywhere the program runs, and when it is wrong you can read the exact bytes it sent. 2. **Move to the browser method** when replay genuinely cannot reproduce the login: the request is assembled or signed by page JavaScript, the flow has steps a single request cannot express, or the body changes shape between attempts. 3. **Reach for a client script** when you need browser execution *and* deterministic control of the steps - the heuristics are the part you are replacing. 4. **Check the runner before you commit.** A browser-driven login on an image built without a browser fails at run time, not at plan time, and the plan will have parsed perfectly. ## The judgment an interviewer is listening for The wrong answer is "browser-based, it handles everything". The right one names the cost: a browser in the pipeline is a dependency, a source of flakiness and a chunk of wall-clock time on every scan, bought to solve a problem the cheap method genuinely cannot. The other half of the judgment is **verifiability** - whichever method you pick, you need to be able to tell, after the run, that it worked; the replayed request is easier to inspect, and the browser method compensates by being able to log in to things the replay cannot reach at all.

  • What does the browser-based method do that makes it able to work out the login request at all?
    It starts its own local server and points the browser it drives at it, so every request the login produces passes through the add-on. After submitting the form it waits for the authentication request to be identified in that traffic. You give it a login page URL; it derives the request that a replay method would have made you write out by hand.
  • Where does the client-script method sit between the two?
    It extends core's script-based method but runs its script against a browser session rather than building an HTTP message. You get browser execution with deterministic, scripted steps - which is the right trade when you need a real page rendered but do not want the field-detection heuristics deciding anything.
  • What is the failure mode of each when it goes wrong?
    Both fail quietly. The replay method posts a body that is subtly wrong - a stale anti-CSRF token, a mistyped placeholder, the wrong encoder - and gets a normal response back. The browser method fills a field it misidentified, or none. Neither raises an error, which is why a behind-the-login assertion matters more than the choice between them.

A replayed login is a phone script you wrote out and hand over to be read aloud: exact, repeatable, and wrong in exactly the way you wrote it wrong. A browser-driven login is asking someone to make the call themselves and tell you afterwards what was said.

saying these in an interview costs you the question

  • Says the browser method is always the safer default
  • Ignores that a browser-driven login needs a browser in the runner
  • Claims the browser method is told which fields to fill
  • Thinks replaying a login handles JavaScript-signed requests
  • Assumes either method reports a login it got wrong