NJS Questions and/or Bugs

[Lance Dockins]

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.

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

    r.internalRedirect('@php');
}

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.
https://share.wordkeeper.com/n4SEbeW3mUqZXtejjXsS


--
Lance Dockins
Minister of Magic
WordKeeper
Office: 405.585.2500
Cell: 405.306.7401
https://wordkeeper.com
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 http://127.0.0.1:8080/test?foo=bar\&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>