NJS Access Filter

[lancedockins]

Are there any plans to add a js_access_filter? We currently use Lua to control some aspects of access to different locations. While you can sort of achieve this with either js_set or other existing NJS directives, the only way to do this for access filters that also require access to the request body is with js_content. So if you need to filter access based on the request body, you basically have to use js_content. While that does seem to work, right now it appears that the only way to do this for a location that is also passed to FastCGI is to use an internal redirect to a named location. That's OK as a workaround but it does complicate the use of location specific filters for things like js_header_filter or js_body_filter because it redirects the entire request internally to a global named location. A js_access_filter directive that has access to the request body would solve this (just like it currently does with Lua and OpenResty's integration with Nginx)

[crasyangel]

What is access_filter? access phase or header_filter?

[lancedockins]

I'm referring to the access phase and filtering that (to change the allow/deny/status type of response). There's already a header filter in NJS so obviously there is no need for another one for that.

[crasyangel]

I'm referring to the access phase and filtering that (to change the allow/deny/status type of response). There's already a header filter in NJS so obviously there is no need for another one for that.

How access phase filter? filter is not the place where make response

[lancedockins]

I don't think that you are following what I'm talking about at all. Nginx has an access phase. That phase happens before the content phase where the response is set. That phase is specifically related to request authorization. What I'm talking about is tapping into that phase so that the determination of whether the user can proceed or not is done programmatically with JS instead of a simple allow/deny in the location block. If you need more information about that phase, see the Nginx docs.
https://nginx.org/en/docs/dev/development_guide.html

The concept that I'm describing is not remotely new. It's been in Lua's Nginx extension logic for years.
https://github.com/openresty/lua-nginx-module#access_by_lua_blockgg

It wouldn't be exactly the same with NJS. But it's the same concept. There are legitimate reasons to do this. They're not about setting the content of the response. They are about allowing/denying the entire request.

[crasyangel]

I don't think that you are following what I'm talking about at all. Nginx has an access phase. That phase happens before the content phase where the response is set. That phase is specifically related to request authorization. What I'm talking about is tapping into that phase so that the determination of whether the user can proceed or not is done programmatically with JS instead of a simple allow/deny in the location block. If you need more information about that phase, see the Nginx docs. https://nginx.org/en/docs/dev/development_guide.html

The concept that I'm describing is not remotely new. It's been in Lua's Nginx extension logic for years. https://github.com/openresty/lua-nginx-module#access_by_lua_blockgg

It wouldn't be exactly the same with NJS. But it's the same concept. There are legitimate reasons to do this. They're not about setting the content of the response. They are about allowing/denying the entire request.

Yes, I understood. But the nginx access phase is totally different from header_filter or body_filter. The 'access_filter' is weird that doesn't make any sense at all

[drsm]

@crasyangel

the access_by_lua_block runs after the nginx access phase, so unaffected by satisfy any|all

@lancedockins

why not to use auth_request to js_content ?

[xeioex]

@lancedockins

The standard way to implement the logic of access filter is to use /auth_request with js_content.

Take a look at following examples.

[lancedockins]

@drsm and @xeioex Thank you for that context. I had a suspicion that that filter might run technically after the access phase (e.g. post access, pre content). It said that it was part of the "tail" of the access phase.

How would that work in the context of a FastCGI backend? All of the examples demonstrate it in the context of a proxy backend. Would you just create an internal location, set the js_content filter of the internal location to use the sort of logic that I'm describing, set an auth_request to the internal location from the primary location, and then configure the rest of the primary location to just fastcgi_pass directly?

e.g.

`/primary-location {
auth_request /access-filter;

fastcgi_pass unix:/path/to/sock;

}

/access-filter {
internal;

js_content http/access.js;

}

access.js

// Logic to parse request body and approve/deny the request?`

Also, in terms of implementation, isn't that a lot more cumbersome than just having an access filter? And if the intended response was a 444 rather than 401 or 403, wouldn't that either be impossible or require passing back content to the auth_request_var that you would use to deny the request with 444 in the primary location?

[xeioex]

@lancedockins

A js_access_filter directive that has access to the request body would solve this

there is also an issue with having request body in access phase. By nginx design, access phase is a relatively early phase where body is not read yet (because the body can be quite large, this way nginx avoids DOS attacks).

[lancedockins]

That makes sense. But I think that the presence of the auth_request directive sort of illustrates the value here.

That may also explain why the OpenResty version requires you to specifically retrieve the request body in any extension code - perhaps some under the hood internal magic when you do that.

Regardless, though, I don't want to get hung up on the phase or name of this. The concept is obviously valuable or there wouldn't be an auth_request directive. Sure, it runs later in the processing phase than the "access" phase specifically due to the DOS side of things but if it's still running before the content phase then you're actually getting a happy middle ground where you have the DOS protection from not retrieving the request body in earlier phases and the benefit of having access to the request body for additional auth/filtration before the content phase (but after the access phase).

It could be something that's just named differently like js_auth_filter instead and would serve as a simpler way to do the same sort of thing that we're talking about with auth_request.

[lcrilly]

This workaround isn't pretty but it might be helpful.
https://www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-2-protecting-backend-services/#request-bodies

[lancedockins]

@lcrilly Yep. That is very helpful. That's another example of the exact type of functionality that I'm looking for.

Question about that one:
Is the r.variables.upstream variable just a made up variable name or named upstream group? Or is that a first party Nginx variable name? I didn't see that one specifically in the Nginx docs. I'm assuming that (either way), the implication here is that there is an upstream group defining the upstreams, that that would just be referenced like fastcgi_pass backend; in the location block, and that the NJS example here would either pass to that backend or not based off of the returned value for r.variables.upstream (in the part of the example that uses that).

That said, though, the fact that the workaround is this cumbersome sort of illustrates the point of my issue/request entirely. There is obviously a need for the sort of functionality that I'm talking about. Otherwise things like auth_request and your article wouldn't even be a thing.

I think a lot of people would much prefer to use something like NJS over Lua strictly because it's first party and JavaScript instead of Lua. I know I fit that category. But on this particular functionality need, OpenResty's Lua integration API is hands down, dominating over NJS's ways of achieving the same thing. With NJS, all available solutions are workarounds (more or less). With the OpenResty Lua API, that's a first party capability that goes right into the location block of interest without having to create a variety of placeholder/stub location blocks just to do request body handling. That's what I'm suggesting - that NJS adopt some sort of first party way to do this sort of thing as well. I'm not proposing that NJS adopt every one of their conventions or anything. Things like js_set are actually pretty creative. But hooking into an auth/pre-content phase

[lcrilly]

$upstream is a user-defined variable to indicate the success target for a given location
https://gist.github.com/nginx-gists/6a8e7c65fdc41bc955f7e67a1d475469#file-warehouse_api_jsonbody-conf-L15

With FastCGI you'll need a fastcgi_pass target to handle the requests that fail your auth check. An error-handler to send a 401 response (or similar).