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

feat(key-auth) optionally search the request body for credentials #2493

Merged
merged 1 commit into from May 4, 2017

Conversation

Projects
None yet
2 participants
@p0pr0ck5
Contributor

p0pr0ck5 commented May 3, 2017

Summary

This commit provides an optional plugin configuration field to
search the request body for the authentication credentials. This
behavior respects the hide_credentials field.

This commit also expands the access test suite to cover a few more
use cases.

Full changelog

  • add the key_in_body configuration option
  • add related tests
  • expand config.hide_credentials tests to cover all use cases (headers, query string, req body)
feat(key-auth) optionally search the request body for credentials
This commit provides an optional plugin configuration field to
search the request body for the authentication credentials. This
behavior respects the hide_credentials field.

This commit also expands the access test suite to cover a few more
use cases.

@p0pr0ck5 p0pr0ck5 merged commit d3e9071 into master May 4, 2017

0 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details

@p0pr0ck5 p0pr0ck5 deleted the feat/key-auth-body branch May 4, 2017

@p0pr0ck5

This comment has been minimized.

Show comment
Hide comment
@p0pr0ck5

p0pr0ck5 May 4, 2017

Contributor

Thanks, minor style fixes applied and merged.

Contributor

p0pr0ck5 commented May 4, 2017

Thanks, minor style fixes applied and merged.

@thibaultcha

This comment has been minimized.

Show comment
Hide comment
@thibaultcha

thibaultcha May 5, 2017

Member

I made a slight oversight: we should have updated the "No API key found in ..." error message returned on HTTP 401, since we now take the body in consideration as well. Maybe even better, we could change it to simply: "No API key provided" or something similar. After all, where else than the headers, the querystring, and the body could once insert an arbitrary value? Not that many places...

Member

thibaultcha commented May 5, 2017

I made a slight oversight: we should have updated the "No API key found in ..." error message returned on HTTP 401, since we now take the body in consideration as well. Maybe even better, we could change it to simply: "No API key provided" or something similar. After all, where else than the headers, the querystring, and the body could once insert an arbitrary value? Not that many places...

@p0pr0ck5

This comment has been minimized.

Show comment
Hide comment
@p0pr0ck5

p0pr0ck5 May 5, 2017

Contributor

@thibaultcha would the resulting change in the return values constitute a breaking change, and thus belong in the next major release? or this is something we're comfortable patching now?

Contributor

p0pr0ck5 commented May 5, 2017

@thibaultcha would the resulting change in the return values constitute a breaking change, and thus belong in the next major release? or this is something we're comfortable patching now?

@thibaultcha

This comment has been minimized.

Show comment
Hide comment
@thibaultcha

thibaultcha May 5, 2017

Member

I think as long as the HTTP status code doesn't change, this is hardly considered a breaking change. It should be fine.

Member

thibaultcha commented May 5, 2017

I think as long as the HTTP status code doesn't change, this is hardly considered a breaking change. It should be fine.

@p0pr0ck5

This comment has been minimized.

Show comment
Hide comment
@p0pr0ck5

p0pr0ck5 May 5, 2017

Contributor

👍 wasn't sure about our stance on the message content itself (i imagine a UI application working based on the contents of the message field). done in #2502.

Contributor

p0pr0ck5 commented May 5, 2017

👍 wasn't sure about our stance on the message content itself (i imagine a UI application working based on the contents of the message field). done in #2502.

thibaultcha added a commit to Kong/docs.konghq.com that referenced this pull request May 25, 2017

thibaultcha added a commit to Kong/docs.konghq.com that referenced this pull request May 25, 2017

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