In REST Assured, what do the three arguments of FormAuthConfig tell auth().form(...) to do?

## The three arguments, in order `FormAuthConfig` has one public three-argument constructor, and the arguments are all strings describing the **form**, never the user: 1. `formAction` — the path the login form submits to, for example `/catalogue/perform_login`. This is the `action` attribute of the `<form>` element, not the address of the page the form is displayed on. 2. `userNameInputTagName` — the `name` attribute of the input that carries the username, for example `staff_id`. 3. `passwordInputTagName` — the `name` attribute of the password input, for example `staff_pin`. The credentials themselves go to the DSL call: `auth().form("clerk", "opensesame", config)`. A common first mistake is to put the username and password into the config; the config's job is to say *where* they go and *what they are called*, so it can be built once and shared across a suite. ## What REST Assured does with them Form authentication is implemented by an internal filter, not by a header. Once the filter has the three values it builds the login request itself: - It creates a fresh specification with `auth().none()` and CSRF disabled, so the login call is not itself authenticated or token-decorated. - It adds two form parameters — the username input name mapped to your username, the password input name mapped to your password. - It builds the login URL from the **scheme, host and port of the request under test** plus the form action, prefixing a `/` if the action does not already start with one. - It `POST`s that request, then copies `loggedInResponse.cookies()` onto your original request specification and lets the real call proceed. That last step is the whole point: the session cookie the catalogue hands back is what makes `GET /catalogue/loans/overdue` succeed a moment later. ## Why the config exists at all Without it, REST Assured has to work the same three values out for itself. `FormAuthConfig.requiresParsingOfLoginPage()` returns `true` when the action, the username input name or the password input name is blank — which is exactly what the two-argument `auth().form(user, password)` leaves behind. The filter then fetches a login page, parses it with `XmlPath` in HTML compatibility mode, and greps for the first `<form>` element's action plus one input typed `text` and one typed `password`. That costs a round trip on every test and is only as reliable as the markup: | With the three-argument config | With no config | |---|---| | one request: the login `POST` | two requests: fetch the page, then `POST` | | the names you read off the page | names guessed from the HTML | | unaffected by extra forms or inputs | broken by a second text input or an earlier form | ## `springSecurity()` and the other shortcuts `FormAuthConfig` carries a few statics and builders worth knowing: - `FormAuthConfig.springSecurity()` returns a config pre-filled with `/j_spring_security_check`, `j_username` and `j_password` — the classic Spring Security names, and nothing more clever than those three strings. - `FormAuthConfig.formAuthConfig()` (and the no-argument constructor) returns an **empty** config, which is the explicit way of saying "detect everything". - `withAdditionalField("branch")` and `withAdditionalFields("a", "b", ...)` name hidden inputs that the server also wants submitted. REST Assured reads their values out of the login HTML, so using them forces the extra fetch back on even if you supplied all three main values. - `withLoggingEnabled()` and its `LogDetail` / `LogConfig` overloads print the login request and response, which is otherwise invisible because the exchange happens inside a filter. - Every one of these returns a **new** `FormAuthConfig` — the class is immutable, so chain the calls rather than expecting an instance to mutate. ## Reading the values off a real page Given a municipal catalogue login screen like this: ```html <form action="/catalogue/perform_login" method="POST"> <input type="text" name="staff_id"> <input type="password" name="staff_pin"> <input type="submit" value="Sign in"> </form> ``` the config writes itself: `new FormAuthConfig("/catalogue/perform_login", "staff_id", "staff_pin")`. Three checks are worth making every time you build one: - Take the action from the `<form>` tag, not from the browser's address bar. - Take the `name` attributes, not the `id` attributes — the server reads names when the form is submitted. - Confirm the method really is `POST`; the filter always posts, so a form the server expects as a `GET` will not work through this path. ## Where it fits in a suite Because the config is immutable and cheap, the usual shape is one constant shared by every test that needs a signed-in catalogue session, with the credentials themselves coming from configuration rather than the source. If a test does **not** need a session, leave form auth off entirely rather than authenticating and ignoring the result — every `auth().form(...)` costs at least one extra request, and two if the config is incomplete.