Oh… and to reiterate, I get similarly empty object responses when access the
variables and rawVariables objects. Most of them seem to be empty objects,
actually.
--
Lance Dockins
On Aug 11, 2021, 9:31 PM -0500, Lance Dockins <la...@wordkeeper.com>, wrote:
> 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
>
> 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
