requestor job to support additional headers

This is a note from Simon - Please raise an enhancement request issue for the requestor job to support additional headers - these should support env vars which will allow you to specify the bearer token.

This is the issue / feature I would request:

I set up a requestor for a valid request that I captured. The requestor does not let me add the bearer token needed for authorization.

For example, this is the request as captured:

POST https://api.mydomain.com/search HTTP/1.1
Content-Type: application/json
Authorization: Bearer <A Bunch of data that represents the token...>
Content-Length: 162
Host: api.mydomain .com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.12 (Java/11.0.12)

{<SOME DATA>}

The request job in the yaml looks like this:

jobs:
- parameters:
    user: ""
  requests:
  - url: "https://api.mydomain.com/search"
    name: ""
    method: "POST"
    data: "{<SOME DATA>}"
    responseCode: 200
  name: "requestor"
  type: "requestor"

Can I somehow paste the valid token in the yaml file? If so what is the syntax?

[njmulsqb]

So as discussed in IRC channel, the solution to above issue is that I wasn’t deploying the changes to Zap Add on, each code change needs to be replicated to the addon file as zap reads the changes from addon file. The solution is to run gradlew addOns:automation:copyZapAddOn when Zap changes needs to be deployed. This needs to be run whenever I want to see the changes. To check if the addon is deployed properly or not, go to zap --> addons --> automation --> click on it and see where the plugins are being stored, go to that directory and check if the addon file (automation-beta) in this case has updated or not?

[thc202]

an error is being thrown

You need to provide more details, the JobUtils is able to copy List.

but this seems to be just a workaround.

No, it’s not a workaround it’s what needs to be done, otherwise you are breaking other add-ons that are using that constructor.

Can these comments be added to ZAP?

Make sure it’s proper JavaDoc rather than plain code comments though.