Add Authentication Options for DAST API On-Demand screens
What does this MR do and why?
- Currently, from UI we are only setting the username and password when the target_type is
website
. - The changes will allow the users to set the username and password when the target_type is
api
. - The above 2 operations can be done by Graphql mutations but do not have any use case in case of target_type
api
. - On Create action and on supplying target_type
api
we are settingDAST_API_HTTP_PASSWORD_BASE64
ENV andDAST_API_HTTP_USERNAME
username.
Note: For API basic auth we don't need target_url
and other auth options
. We only need username and password from auth options
Testing the changes:
- Sample Graphql that can be used for testing.
mutation($dastSiteProfileUpdateInput: DastSiteProfileUpdateInput!) {
dastSiteProfileUpdate(input: $dastSiteProfileUpdateInput) {
clientMutationId
errors
id
}
}
{
"dastSiteProfileUpdateInput":{
"fullPath":"root/dast-test1",
"id":"gid://gitlab/DastSiteProfile/3",
"profileName":"profile2",
"targetUrl":"https://gitlab.com/",
"auth":{
"enabled":false, "username": "test2", "password": "pass2"
}
}
}
mutation($dastSiteProfileCreateInput: DastSiteProfileCreateInput!) {
dastSiteProfileCreate(input: $dastSiteProfileCreateInput) {
clientMutationId
errors
id
}
}
{
"dastSiteProfileCreateInput":{
"fullPath":"gitlab-org/go-fuzzing-example8",
"profileName":"Open-source intermediate methodology",
"targetUrl":"http://example18.test",
"excludedUrls":"http://example18.test/signout",
"requestHeaders":"Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0",
"auth":{
"enabled":true,
"submitField": "css:button[type=\"submit\"]"
}
}
}
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #350514 (closed)
Edited by Mayra Cabrera