Namespace ngx.ctx values

[thibaultcha]

Currently plugins and core use ngx.ctx with many key/values. Apart from the fact that conflicting names could happen anytime (rate-limiting and quota plugins could use similar ngx.ctx.usage values), it makes code less readable especially in plugins using ngx.ctx values from both themselves and the core.

To limit this, we should probably namespace values stored in ngx.ctx, by simply nesting them into tables: ngx.ctx.kong = {...} for the core and ngx.ctx.plugin_name = {...} for plugins for example.

Another thing we could do, and we have been discussing this for a while, is to pass references to those variables directly to plugins handlers, such as having:

-- in kong.lua, note the plugin_ctx variable returned by the iterator
-- basically plugins_iterator could check if plugin X has a namespace in ngx.ctx, and
-- create it if not.
local ctx_kong = ngx.ctx.kong
for plugin, plugin_conf, plugin_ctx in plugins_iterator(loaded_plugins, "access") do
  plugin.handler:access(plugin_conf, ctx_kong, plugin_ctx)
end

-- In rate-limiting access.lua
function _M.access(config, ctx_kong, ctx_rate_limit)
  -- those reference can be manipulated and passed around all handlers
end

---

This is in the same spirit as the long desired improvement of passing configuration and dao_factory along to plugin handlers too (See #709), instead of having them as globals from the init_by_lua phase (!). It is slightly out of the scope of this particular issue but ideally, the final signature of a plugin handler function should be:

function _M.access(plugin_config, plugin_ctx, kong_ctx, dao_factory, kong_config)
  -- no more global lookup, and probably less ngx.ctx lookups too.
end

[Tieske]

iirc nginx can retain some state, so is it possible to use a coroutine based approach? then all the generic stuff needs to be passed only upon creating the coroutine, and for each request (yield/resume cycle) only the specific data needs to passed.

This would also make it cheaper to separate (as in sandbox) the plugin code from the core as the sandbox would be created and setup only once)

But that all depends on how well nginx/openresty can retain state.

[thibaultcha]

lua_ngx indeed retains some state, precisely in the ngx.ctx variable, which has the lifetime of the current request being executed. lua_ngx phase handlers also already run sandboxed in coroutines, so I am not sure what you are thinking about. Sandboxing the plugins handlers from the core (that is already sandboxed by lua_ngx)? How would you do that? I'm not sure this is what we want, plugins do need to access the whole ngx_lua environment. After all, Kong is an OpenResty application.

[Tieske]

never mind, even if you could it would mean to have most of Kong available as a global, which interferes with the nginx principle of request isolation. Works for Lua, but not with OpenResty, conceptually a bad idea. Sorry for the noise.

Sandboxing plugins comes back to running untrusted code. I think we discussed it elsewhere as part of the request to spin out the plugins from the core.

Back to the initial post;

ngx.ctx.kong = {...} for the core and ngx.ctx.plugin_name = {...} for plugins for example.

I'd make the latter ngx.ctx.kong.plugins.plugin_name = {...} as it has better isolation for name collisions.

I like the idea of the plugin handler signature spelling out the individual elements.

[bungle]

The PDK implements this, so I will close this.

[thibaultcha]

Yes! Documentation for future reference: https://docs.konghq.com/1.0.x/pdk/kong.ctx/

[neomatrix1993]

How do you put debug points in lua, like we do intellij etc. Its super hard to dev anything in lua. Haven't found anything good to dev it in.

[Tieske]

Log it. See https://discuss.konghq.com/t/best-practices-for-kong-debugging-example/182