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.

Sign up for GitHub

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

Jump to bottom

[TT-2216] - Suport passing custom signature in a query parameter #3511

Closed
gmaiztegi opened this issue Mar 30, 2021 · 1 comment
Closed

[TT-2216] - Suport passing custom signature in a query parameter #3511

gmaiztegi opened this issue Mar 30, 2021 · 1 comment
Labels
enhancement zendesk

Comments

@gmaiztegi
Copy link

gmaiztegi commented Mar 30, 2021 •
edited
Loading

Is your feature request related to a problem? Please describe.
Tyk supports custom signature validation, which is great, but I am currently managing a migration from Mashery that puts the signature in a query parameter, which is currently not supported.

Describe the solution you'd like
I would like to be able to pass the signature in a query parameter, just like we can pass authentication tokens there.

Describe alternatives you've considered
Not really.

Additional context
Working on a PR right now.
@gmaiztegi gmaiztegi mentioned this issue Mar 30, 2021
Closed
17 tasks
@n2linux
Copy link

n2linux commented Mar 30, 2021

@gmaiztegi Thanks so much for creating this issue and working on a PR! 🥇

We will get someone assigned to review everything and will be in touch.

@vverbani vverbani changed the title Suport passing custom signature in a query parameter [TT-2216] - Suport passing custom signature in a query parameter Apr 14, 2021
buger pushed a commit that referenced this issue Sep 10, 2021
@furkansenharputlu
[TT-2216] Gmaiztegi signature param (#3662)
b187b3f 
<!-- Provide a general summary of your changes in the Title above -->

## Description
This PR adds `use_param` and `param` to the signature configuration, in order to be able to pass the signature as a query parameter (I would appreciate some help to know how to correctly document these new fields). These parameters behave very similar to those regarding the token.

## Related Issue

#3511

## Motivation and Context

bde50bc added support for a Mashery-style signature validation, but it only supports getting the signature from a header. Mashery supports passing the signature in a query parameter, so it would be great to support this feature and mimic this behaviour.

## How This Has Been Tested

I have to say I'm super new to the Golang community so I tested this only with the test added to this PR, so I would appreciate some feedback while I build the Docker image and test it inside Kubernetes.

## Screenshots (if appropriate)

## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes that apply -->
<!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! -->
- [X] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own
      fork, don't request your `master`!
- [X] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start
      *your branch* off *our latest `master`*.
- [X] My change requires a change to the documentation.
  - [X] If you've changed APIs, describe what needs to be updated in the documentation.
  - [ ] If new config option added, ensure that it can be set via ENV variable
- [ ] I have updated the documentation accordingly.
- [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor`
- [ ] When updating library version must provide reason/explanation for this update.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
- [X] Check your code additions will not fail linting checks:
  - [X] `go fmt -s`
  - [X] `go vet`
furkansenharputlu added a commit that referenced this issue Sep 23, 2021
@furkansenharputlu
[TT-2216] Gmaiztegi signature param (#3662)
44b7078 
<!-- Provide a general summary of your changes in the Title above -->

This PR adds `use_param` and `param` to the signature configuration, in order to be able to pass the signature as a query parameter (I would appreciate some help to know how to correctly document these new fields). These parameters behave very similar to those regarding the token.

#3511

bde50bc added support for a Mashery-style signature validation, but it only supports getting the signature from a header. Mashery supports passing the signature in a query parameter, so it would be great to support this feature and mimic this behaviour.

I have to say I'm super new to the Golang community so I tested this only with the test added to this PR, so I would appreciate some feedback while I build the Docker image and test it inside Kubernetes.

<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

<!-- Go over all the following points, and put an `x` in all the boxes that apply -->
<!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! -->
- [X] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own
      fork, don't request your `master`!
- [X] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start
      *your branch* off *our latest `master`*.
- [X] My change requires a change to the documentation.
  - [X] If you've changed APIs, describe what needs to be updated in the documentation.
  - [ ] If new config option added, ensure that it can be set via ENV variable
- [ ] I have updated the documentation accordingly.
- [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor`
- [ ] When updating library version must provide reason/explanation for this update.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
- [X] Check your code additions will not fail linting checks:
  - [X] `go fmt -s`
  - [X] `go vet`
furkansenharputlu added a commit that referenced this issue Sep 23, 2021
@furkansenharputlu
[TT-2216] Gmaiztegi signature param (#3662)
2a9a933 
<!-- Provide a general summary of your changes in the Title above -->

This PR adds `use_param` and `param` to the signature configuration, in order to be able to pass the signature as a query parameter (I would appreciate some help to know how to correctly document these new fields). These parameters behave very similar to those regarding the token.

#3511

bde50bc added support for a Mashery-style signature validation, but it only supports getting the signature from a header. Mashery supports passing the signature in a query parameter, so it would be great to support this feature and mimic this behaviour.

I have to say I'm super new to the Golang community so I tested this only with the test added to this PR, so I would appreciate some feedback while I build the Docker image and test it inside Kubernetes.

<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

<!-- Go over all the following points, and put an `x` in all the boxes that apply -->
<!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! -->
- [X] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own
      fork, don't request your `master`!
- [X] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start
      *your branch* off *our latest `master`*.
- [X] My change requires a change to the documentation.
  - [X] If you've changed APIs, describe what needs to be updated in the documentation.
  - [ ] If new config option added, ensure that it can be set via ENV variable
- [ ] I have updated the documentation accordingly.
- [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor`
- [ ] When updating library version must provide reason/explanation for this update.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
- [X] Check your code additions will not fail linting checks:
  - [X] `go fmt -s`
  - [X] `go vet`
furkansenharputlu added a commit that referenced this issue Jan 25, 2022
@furkansenharputlu
[TT-2216] Gmaiztegi signature param (#3662)
5ede1fe 
<!-- Provide a general summary of your changes in the Title above -->

This PR adds `use_param` and `param` to the signature configuration, in order to be able to pass the signature as a query parameter (I would appreciate some help to know how to correctly document these new fields). These parameters behave very similar to those regarding the token.

#3511

bde50bc added support for a Mashery-style signature validation, but it only supports getting the signature from a header. Mashery supports passing the signature in a query parameter, so it would be great to support this feature and mimic this behaviour.

I have to say I'm super new to the Golang community so I tested this only with the test added to this PR, so I would appreciate some feedback while I build the Docker image and test it inside Kubernetes.

<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

<!-- Go over all the following points, and put an `x` in all the boxes that apply -->
<!-- If you're unsure about any of these, don't hesitate to ask; we're here to help! -->
- [X] Make sure you are requesting to **pull a topic/feature/bugfix branch** (right side). If pulling from your own
      fork, don't request your `master`!
- [X] Make sure you are making a pull request against the **`master` branch** (left side). Also, you should start
      *your branch* off *our latest `master`*.
- [X] My change requires a change to the documentation.
  - [X] If you've changed APIs, describe what needs to be updated in the documentation.
  - [ ] If new config option added, ensure that it can be set via ENV variable
- [ ] I have updated the documentation accordingly.
- [ ] Modules and vendor dependencies have been updated; run `go mod tidy && go mod vendor`
- [ ] When updating library version must provide reason/explanation for this update.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
- [X] Check your code additions will not fail linting checks:
  - [X] `go fmt -s`
  - [X] `go vet`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement zendesk
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@n2linux @gmaiztegi @vverbani @christtyk