NJS Questions and/or Bugs

Lance Dockins lance at wordkeeper.com
Thu Aug 12 02:31:41 UTC 2021

Hi Sergey,

Sure.  The tool that I’m using for HTTP testing is just a GUI interface directly to HTTP so it works the same as a browser would since it’s just straight HTTP.  It supports curl mode too but that’s just a alternative wrapper for HTTP and none of the methods that we’re using to interface with this via POST (including direct browser POST) are producing different results.

I realize that the implementation in the access function right now makes no sense.  This is just a stripped down version of where this will eventually go specifically for the sake of testing POST args access.  I get the same results even if we remove the r.internalRedirect statement.

function access(r){
    r.return(200, JSON.stringify(r.args));


export default {access}

The location block for the config file:
# Pass PHP requests to PHP-FPM
location ~ \.php$ {
	limit_req zone=post_limit burst=5 nodelay;
	limit_req_status 429;

	add_header Content-Type text/plain;
	js_content dbadmin.access;

location @php{
	set $no_cache 1;
	include includes/fastcgi.conf;

	fastcgi_pass unix:/var/run/php-fpm/dbadmin.sock;
	# fastcgi_cache dbadmin;

The relevant import directive from nginx.conf
js_import scripts/security/dbadmin.js;

Incidentally, this config also illustrates why I was asking about access phase filters.  In LuaJIT/OpenResty, we can tap into the access phase to deny a request without having to define a separate location block to internalRedirect to.   It seems like the only way to simulate this with NJS right now is to define a location, use js_content to hand off to NJS for content, and then internalRedirect or sub request to a different location block to allow requests through.  It’s simpler if there is just a way to control access in the access phase without having to use a workaround in the content phase to try to add access control first and then run the content phase normally.

In any case, I also wanted to confirm that the curl method of doing the POST doesn’t really change anything as well.  Here’s a screenshot along with the corresponding curl request that the app runs.

Lance Dockins
Minister of Magic
Office: 405.585.2500
Cell: 405.306.7401
On Aug 11, 2021, 9:20 PM -0500, Sergey A. Osokin <osa at freebsd.org.ru>, wrote:
> Hi Lance,
> On Wed, Aug 11, 2021 at 09:05:32PM -0500, Lance Dockins wrote:
> > Hi Sergey,
> >
> > Thank you.  Perhaps something is going wrong with the implementation
> > of r.args that we’re using.  I’m just getting an empty JS object for
> > POST vars.  Args only seems to work for query string vars for me.
> >
> > Here’s the key config info.
> >
> > In the location block for the route that I’m testing:
> >
> > add_header Content-Type text/plain;
> > js_content dbadmin.access;
> >
> > The dbadmin.access function just has this at the top of the function right now:
> > r.return(200, JSON.stringify(r.args));
> Could you please share a couple of things:
> - whole dbadmin.js file;
> - a server block from nginx configuration file with a full location
> description
> For development and testing I'd recommend to use:
> - curl command line utility, i.e. something like:
> % curl -v --data-binary @test.bin\&baz=1
> - enable debugging as described at http://nginx.org/en/docs/debugging_log.html
> so you'll be able to see what's going on with a request processing
> --
> Sergey
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20210811/5e88da60/attachment.htm>

More information about the nginx mailing list