Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REQ] [Go][Client]Accept privateKey content as string in http-signing #8569

Closed
code-lucidal58 opened this issue Jan 28, 2021 · 0 comments · Fixed by #8570
Closed

[REQ] [Go][Client]Accept privateKey content as string in http-signing #8569

code-lucidal58 opened this issue Jan 28, 2021 · 0 comments · Fixed by #8570

Comments

@code-lucidal58
Copy link
Contributor

In signing.go file in client/go, the http signing struct expects privateKey file path. In a scenario, when the text file is not present in the local system, and it is sourced from cloud, this property poses a restriction. privateKey is a private property and there is no setter function for the same.

Proposed solution

Add a setter function in signing.go to allow sending the key content as string. Overal, both the methods, privateKeyAsFile and privateKeyAsString will be allowed. No change to existing struct of HttpSignatureAuth is required. Hence, this feature will not be a breaking change.

Alternative solutions tried

For my usecase, I do not have the privateKey as a file. Fetching it and storing in a file and then using it is not a feasible solution. I do not want to leave that file in the local system. Hence, I shall be deleting it after each request to endpoint. This will cause error when requests are send in concurrent fashion. One request might be creating the file, while other would be trying to delete it.

If each time, a uniquely names file is generated, for a bulk request/response, this level of I/O will hinder the performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant