Configuring the Login — interview questions

Which ZAP login methods ship in core, which come from the authhelper add-on, and why does the difference matter?

middlemust knowfreq 70%

answer

five in the program, three in an add-on
one builds a message, one drives a browser
valid at parse, resolved much later
the registry lookup is what fails

basics

~20 s

Core registers five authentication method types: manual, http, form, json and script. The authhelper add-on adds browser-based, client-script-based and auto-detect logins. A plan may name all eight, but the last three fail unless that add-on is installed.

solid answer

~40 s

Core's ExtensionAuthentication registers five method types - manual, http, form, json and script - and all five build and send an HTTP message. The authhelper add-on registers three more - browser, client and autodetect - and all three drive a real browser through the selenium add-on. An automation plan's authentication.method accepts all eight strings, and it validates that list when it parses. It only resolves the three add-on methods later, when it builds the environment, by asking core's registry for the type; if authhelper is absent, that lookup finds nothing and the environment reports a bad authentication type. So a plan naming browser is schema-valid on a build that cannot run it, and the failure arrives at context-build time rather than parse time.

Core's `ExtensionAuthentication` registers **five** method types - `manual`, `http`, `form`, `json` and `script` - and all five build and send an HTTP message. The **`authhelper` add-on** registers three more - `browser`, `client` and `autodetect` - and all three drive a real browser through the `selenium` add-on. An automation plan's `authentication.method` accepts all eight strings, and it validates that list when it *parses*. It only resolves the three add-on methods later, when it builds the environment, by asking core's registry for the type; if `authhelper` is absent, that lookup finds nothing and the environment reports a bad authentication type. So a plan naming `browser` is schema-valid on a build that cannot run it, and the failure arrives at context-build time rather than parse time.

code

yaml · 7 lines

yaml

authentication:
  method: browser
  parameters:
    loginPageUrl: "https://example.com/login"
# no loginRequestUrl and no loginRequestBody:
# the add-on drives a browser and identifies
# the authentication request from the traffic

go deeper

for a junior

Learn to say which half you mean. Naming the owner - core's form method, the add-on's browser method - is the habit that keeps this subject straight.

for a middle

Explain the two-stage resolution: the method string is checked against a fixed list when the plan is parsed, and the actual type is looked up later when the context is built.

for a senior

Show that you validate the runner, not just the plan. A browser-driven login needs the add-on and a browser on the machine, and neither shortage is visible until the environment is built.

for a principal

The generalisable point is that a configuration grammar accepting a value is not a capability claim. Fleet-wide, pin which add-ons a scanning image carries so plans and runners cannot drift apart.

The split, and why it is easy to get wrong

Most of what reads as "ZAP authentication" is spread across two places. Core - the program itself - registers five authentication method types in org.zaproxy.zap.extension.authentication.ExtensionAuthentication, and the authhelper add-on registers three more. Every one of the eight is real, every one of them is named the same way in a plan, and nothing in the plan's own syntax distinguishes them. That is what makes this a mis-attribution trap rather than a lookup.

method value in a plan	where the type lives	what it needs to run
`manual`	core	an HTTP session you selected by hand
`http`	core	a hostname and realm; credentials sent at the HTTP layer
`form`	core	a login URL and a form-encoded body
`json`	core	a login URL and a JSON body
`script`	core	an `authentication` script, plus its engine add-on
`browser`	`authhelper`	`selenium` and a real browser on the machine
`client`	`authhelper`	a client script that drives a browser
`autodetect`	`authhelper`	a browser, and traffic to infer the login from

What core's five have in common

They all build and send an HTTP message, and none of them opens a browser:

form and json share one base class, so they differ only in content type and in how a substituted credential is encoded;
script hands the work to a script whose authenticate returns an HttpMessage;
http supplies credentials at the HTTP layer rather than in a body you author;
manual sends no login at all - it reuses a session you already established by hand.

That is why the five of them need nothing installed beyond the program itself.

What `authhelper`'s three have in common

They all drive a real browser. The browser-based method obtains a WebDriver through the selenium add-on, starts its own local server so the traffic the browser generates passes through it, and then watches for the authentication request rather than being told what it looks like. The client-script method extends core's script method but runs its script against a WebDriver instead of building a message. So:

core's methods are declarative - you describe the request and it is replayed;
authhelper's methods are observational - a browser performs the login and the add-on works out what happened.

The consequence a pipeline actually feels

The automation add-on validates authentication.method against a list of all eight strings when it parses the plan. It resolves the three authhelper methods later, when it builds the environment, by asking core's registry for the matching method type. If authhelper is not installed, the registry returns nothing and the environment records an error for a bad authentication type. Concretely:

A plan that names browser on an installation without authhelper is schema-valid.
It gets past parsing with no complaint at all.
It fails at context-build time, not at scan time, and the message is about the method type rather than about the login.

The same holds for client and autodetect. Existence of a method value in the plan grammar is not evidence that this installation can run it.

A documentation trap on top of the ownership one

The automation add-on can write out a maximal environment template for you to copy from. That shipped template's comment beside method: lists only the five core values. The add-on's shipped help page lists all eight. So the artefact most likely to be copied understates the schema by exactly the three methods that depend on an add-on, which is the most confusing possible subset to leave out - a reader who trusts the template concludes that browser-driven login is not expressible in a plan at all.

How to state this correctly

Say which half you mean, every time. "Core's form-based method" and "the authhelper add-on's browser-based method" are both correct and both checkable; "ZAP's browser login" is the sentence that produces a plan nobody can run. When you are deciding whether a runner can execute a plan, the question is not "does ZAP support this method" - it is "does this build have the add-on, and does this machine have what the add-on needs". For the three authhelper methods the second half of that question means a browser, which an image built to be small may not have.

## The split, and why it is easy to get wrong Most of what reads as "ZAP authentication" is spread across two places. **Core** - the program itself - registers five authentication method types in `org.zaproxy.zap.extension.authentication.ExtensionAuthentication`, and the **`authhelper` add-on** registers three more. Every one of the eight is real, every one of them is named the same way in a plan, and nothing in the plan's own syntax distinguishes them. That is what makes this a mis-attribution trap rather than a lookup. | method value in a plan | where the type lives | what it needs to run | |---|---|---| | `manual` | core | an HTTP session you selected by hand | | `http` | core | a hostname and realm; credentials sent at the HTTP layer | | `form` | core | a login URL and a form-encoded body | | `json` | core | a login URL and a JSON body | | `script` | core | an `authentication` script, plus its engine add-on | | `browser` | `authhelper` | `selenium` and a real browser on the machine | | `client` | `authhelper` | a client script that drives a browser | | `autodetect` | `authhelper` | a browser, and traffic to infer the login from | ## What core's five have in common They all build and send an **HTTP message**, and none of them opens a browser: - `form` and `json` share one base class, so they differ only in content type and in how a substituted credential is encoded; - `script` hands the work to a script whose `authenticate` returns an `HttpMessage`; - `http` supplies credentials at the HTTP layer rather than in a body you author; - `manual` sends no login at all - it reuses a session you already established by hand. That is why the five of them need nothing installed beyond the program itself. ## What `authhelper`'s three have in common They all **drive a real browser**. The browser-based method obtains a WebDriver through the `selenium` add-on, starts its own local server so the traffic the browser generates passes through it, and then watches for the authentication request rather than being told what it looks like. The client-script method extends core's script method but runs its script against a WebDriver instead of building a message. So: - core's methods are **declarative** - you describe the request and it is replayed; - `authhelper`'s methods are **observational** - a browser performs the login and the add-on works out what happened. ## The consequence a pipeline actually feels The `automation` add-on validates `authentication.method` against a list of all eight strings when it **parses** the plan. It resolves the three `authhelper` methods later, when it **builds the environment**, by asking core's registry for the matching method type. If `authhelper` is not installed, the registry returns nothing and the environment records an error for a bad authentication type. Concretely: 1. A plan that names `browser` on an installation without `authhelper` is **schema-valid**. 2. It gets past parsing with no complaint at all. 3. It fails at context-build time, not at scan time, and the message is about the method type rather than about the login. The same holds for `client` and `autodetect`. Existence of a method value in the plan grammar is not evidence that this installation can run it. ## A documentation trap on top of the ownership one The `automation` add-on can write out a maximal environment template for you to copy from. That shipped template's comment beside `method:` lists only the five core values. The add-on's shipped help page lists all eight. So the artefact most likely to be copied understates the schema by exactly the three methods that depend on an add-on, which is the most confusing possible subset to leave out - a reader who trusts the template concludes that browser-driven login is not expressible in a plan at all. ## How to state this correctly Say **which half you mean, every time**. "Core's form-based method" and "the `authhelper` add-on's browser-based method" are both correct and both checkable; "ZAP's browser login" is the sentence that produces a plan nobody can run. When you are deciding whether a runner can execute a plan, the question is not "does ZAP support this method" - it is "does this build have the add-on, and does this machine have what the add-on needs". For the three `authhelper` methods the second half of that question means a browser, which an image built to be small may not have.

The generated maximal environment template lists fewer method values than the code accepts. Which is right?
The code. The shipped template's comment beside `method:` names only the five core values, while the add-on's shipped help page names all eight. The template understates the schema by exactly the three add-on methods - the most confusing subset to omit, since a reader who trusts it concludes browser-driven login cannot be expressed in a plan.
Does naming `script` as the method avoid an add-on dependency?
Partly. The script-based method type itself is core, so the method resolves. But the script has to run in some language, and every scripting engine ships as a separate add-on, so a `script` login still depends on the right engine being installed. The method exists; the capability may not.
What does core's script method get that the form method does not?
Freedom over the credential names. The form and JSON methods are backed by a fixed username-and-password credential type, whereas the script method uses a generic credential type whose parameter names the script declares - so a script login can take a tenant id, an API key or a one-time code as first-class credential fields.

saying these in an interview costs you the question

Calls browser-based login a core feature of the program
Assumes a plan that parses can run on any installation
Says the add-on methods are rejected when the plan is parsed
Treats the generated template's comment as the full schema
Thinks every login method sends plain HTTP requests

open as a page

A ZAP scan finished clean but every page reached was the login page. How do you diagnose the form login?

seniormust knowfreq 65%

basics

~20 s

Read the two recorded authentication messages and compare the login request that was actually sent against a real browser login. The login step reports only preparation and send failures, so a rejected login leaves no error behind.

open as a page

In a ZAP automation plan, what does a context's authentication block hold and what do its users entries hold?

juniorshould knowfreq 55%

basics

~20 s

A context's authentication block says how to log in: the method plus its parameters, such as the login request URL and body. The users list says who logs in, each entry carrying a name and a username and password.

open as a page

In a ZAP form login, what do the tokens in loginRequestBody do, and which methods actually honour them?

middleshould knowfreq 60%

basics

~20 s

They are credential placeholders. Core's form-based and JSON-based login methods replace them with the current user's username and password just before sending the login request, so one configured request serves every identity in the context.

open as a page

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

seniorshould knowfreq 50%

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.

open as a page

§explore

▾roadmaps that cover this4

§questions

Which ZAP login methods ship in core, which come from the authhelper add-on, and why does the difference matter?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The split, and why it is easy to get wrong

What core's five have in common

What authhelper's three have in common

The consequence a pipeline actually feels

A documentation trap on top of the ownership one

How to state this correctly

▾common follow-ups3 questions

▾red flags5 flags

A ZAP scan finished clean but every page reached was the login page. How do you diagnose the form login?

basics

In a ZAP automation plan, what does a context's authentication block hold and what do its users entries hold?

basics

In a ZAP form login, what do the tokens in loginRequestBody do, and which methods actually honour them?

basics

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

basics

The split, and why it is easy to get wrong

What core's five have in common

What authhelper's three have in common

The consequence a pipeline actually feels

A documentation trap on top of the ownership one

How to state this correctly

explore

questions

answer

go deeper

What `authhelper`'s three have in common

What `authhelper`'s three have in common