No API key found in headers or querystring

[shavo007]

Summary

Verifying credentials, I get invalid response back from Kong.

Also should the responses not comply with json api spec?

Steps To Reproduce

1. enable api key plugin for api

http://localhost:8001/apis/locations/plugins

{ "name": "key-auth", "config.key_names": "AUTH_KEY" }

2. create api key for consumer
3. verify the credentials

http://localhost:8000/

Headers:
Host: blah

AUTH_KEY: xyz

4. Get 401 unauthorized
   { "message": "No API key found in headers or querystring" }

Additional Details & Logs

• Kong version 0.9.8
• Operating System OSX

[mtmail]

I was about to report the same issue. I think it's just the documentation.

On https://getkong.org/docs/0.9.x/getting-started/enabling-plugins/ it says "Since you did not specify the required apikey header or parameter, the response should be 403 Forbidden"

In reality following all steps in the setup the response is a "403 Forbidden" with the content {"message":"Invalid authentication credentials"}

Of course when I call the key-auth enabled API with ?apikey=foobar the response is a 403.

In my opinion returning 401 vs 403 is good, especially for API-users to give them a hint they forgot to send the key. Again, I think the documentation just needs to be updated.

[shavo007]

hi @mtmail ,

That is not the issue. The issue is the key name. If the key name is AUTH-KEY, then the subsequent call upstream works. But with underscore, it does not.

[Tieske]

might be openresty issue see last paragraph of https://github.com/openresty/lua-nginx-module#ngxreqget_headers

Not sure though what the status of allowed characters is in headers.

[thibaultcha]

I believe there is an underscore_in_headers directive to be enabled in Nginx.

[shavo007]

Either way, it does not return the correct response. If kong does not support underscore in the key name, then the request to enable api key plugin should have failed with a meaningful error message and this outlined in the api documentation also.

[thibaultcha]

@shavo007 Contributions welcome!

[shavo007]

@thibaultcha i hear you! but i think mashape and the team needs to define a process in place first to consider:

1. The structure of the api documentation (should the resource groups include error responses/response codes for example)
2. Pull request guidelines (should pull request be merged if the code change is not reflected in the api documentation. (if applicable)

To me documentation is source of truth. If this is not up to date, you will have big problems!

Again, this is my opinion from my recent analysis of kong. Take it as you will!

[thibaultcha]

This is more of an unexpected side-effect/bug rather than an overlook over the documentation. Contributors are encouraged to propose sister PRs for changes introduced in this repository. You are welcome to defend your opinion/use case, and propose changes over those 2 topics:

• mentioning this directive in the documentation
• restrict undesired characters from this plugin configuration field, including - eventually - underscores

[shavo007]

it depends how you want to proceed. from the comments sounds like you have two choices:

1)state in api documentation, that api key name does not allow special characters such as underscore. return a 400 bad request if a user attempts to create api key plugin with incorrect value

2. configure kong to handle underscore in key name

is that correct?

[Tieske]

Closing this, fix is in #2142

[shavo007]

good work @Tieske. Can you please add milestone label to the issue so I can keep track?
0.10.0

Thanks,
Shane.

[workcheng]

It seem the bug is still in 0.10.1?I hit the bug in the kong v0.10.1

[Tieske]

@workcheng How did you hit it?