Look the the “input” elements. In this form there are 2 of them with the following names:
Employee[username]
Employee[password]
The login form also uses a CSRF token. It complicates things a bit, but hopefully not too much. The CSRF token must be submitted with the form, however, it’s generated dynamically when the login page is loaded. Therefore:
Dealing with CSRF tokens
When a login page uses a CSRF token, an additional web request must be executed before the authentication request. The web request should fetch the login page itself. For this create a “Web request” action with the following settings:
- Request path - the path of the login page
- Request method - GET
- Response mode - Return response
When executed, the response body will contain the HTML text of the login page, including the login form and the CSRF token in it. In the screenshot above, the “input” element with the CSRF token is named _csrf and has the value TXu9DYANznHlHFhNTHP9...... (I’m too lazy to type it all). Note that the token isn’t visible on the login web page in the browser, because it’s a hidden field (notice the type “hidden” in the “input” element of the token).
Extract the token value using EasyMorph functions (keepbetween() would work nicely here), and include the token and its value into the authentication request as a form value.
Therefore, when a CSRF token is used, the authentication request should contain at least 3 form values:
- username
- password
- CSRF token
For the web form in the screenshot above, the “Web request” action should contain look as below:
Some websites may require the CSRF token additionally submitted as a request header. In this case, the authentication request should be inspected in the browser in order to understand the name of the request header that contains the CSRF token.