Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • O openapi-generator
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,476
    • Issues 3,476
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 402
    • Merge requests 402
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenAPI Tools
  • openapi-generator
  • Issues
  • #8569
Closed
Open
Issue created Jan 28, 2021 by Administrator@rootContributor

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

Created by: code-lucidal58

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.

Assignee
Assign to
Time tracking