Enabling cors plugin on consumer level

[wouthoekstra]

Summary

Enabling the CORS plugin does not seem to be possible on consumer level. According to this issue this might be deliberate: #2235. But no explicit reason there, so I'm going to give it a shot as to why I think CORS is needed on a consumer level:

What I am hoping to achieve is to have the CORS plugin enabled for regular users, but disabled for 'premium' api users. Which would be possible if the plugin can be installed on consumers; in this case an anonymous user that I have already configured with one of the authentication plugins. Other - explicit - users will lack the plugin and won't be bothered by CORS.

Would this be considered a valid use case for the CORS plugin?

[kikito]

Hi, thanks for giving this some thought. We will consider this feature request.

In the meantime, you could try commenting out the following line:

https://github.com/Kong/kong/blob/next/kong/plugins/cors/schema.lua#L29

And restarting Kong. See if that solves your issue.

[wouthoekstra]

Hi! Thx for considering it! I have tried your suggestion. I am now able to install the plugin for a consumer, but it unfortunately doesn't actually work.

To be sure, I've installed the authentication plugin globally, while I installed the CORS plugin on a service. I am not sure, but I hoped this would resolve maybe issues with the order of plugins being handled. Did not work though.

[vasuharish]

Hi, I believe, enabling CORS plugin on consumer level is restricted due the plugin execution order. https://docs.konghq.com/2.0.x/plugin-development/custom-logic/#plugins-execution-order

As per the above documentation, plugins relying on the identity of the consumer have to run after authentication plugins. In case of CORS plugin it will execute before the authentication plugin.

If there is a requirement to use CORS with Consumer then please decrease the CORS plugin priority.

[wouthoekstra]

@vasuharish that seems indeed to be the case. I've got it working now with a modified CORS plugin, so i'm good.

Out of interest though; what would be the use-case of catching requests with CORS before authentication? Is there a performance increase? People might get a different error of course, because this way authentication errors precede CORS errors, but we'll still be able to "disallow" requests from unknown origins after authentication.

Anyway, my issue is resolved since I can make custom plugin. Thank you very much! So except if considering to change the plugin priority is an option, this issue can be closed.

[dsmith-to]

I came across the same issue and would like to see this change. The consumer seems to me to be the most reasonable place for CORS configuration. When we onboard n API user, we create a consumer with unique credentials and access controls. If the user requires CORS, I'd rather not update a plugin on the service level with a long list of origins.