race-condition in servicesManager

[chris-tian89]

Describe the bug

The usage of the artifactory servicesManager Object in go-rutines leads to race-conditions, because it contains the *http.client as a pointer. In concurrent go-rutines those go-rutines are writing to this *http.client in parallel which causes the race-conditions.

newer version v1.24.0 has no change regarding this code.

Current behavior

Currently the race happens in github.com/jfrog/jfrog-client-go@v1.23.4/http/httpclient/client.go at line

• 148: jc.client.CheckRedirect = func(...)
• 155: jc.client.CheckRedirect = nil

Reproduction steps

• create a servicesManager like servicesManager, err := artifactory.New(serviceConfig)
• use a servicesManager-function within a go-routine like servicesManager.CreateUser(userParams) or servicesManager.UpdatePermissionTarget(params) or servicesManager.CreatePermissionTarget(params)

Expected behavior

A solution could be a logical check if a user has set a custom CheckRedirect-function, and if yes (so if it is not nil), no change must be made to that field any more, in order to prevent concurent access of multiple go-rutines. If no custom-value is set by the user the client can behave like today.

JFrog Client-Go version

1.23.4

JFrog CLI version (if applicable)

No response

Operating system type and version

Windows 10

JFrog Artifactory version

No response

JFrog Xray version

No response