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 <o...@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@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
