On Sun, Dec 08, 2019 at 02:29:57PM -1000, Rhys Ferris wrote:
Hi there,
thanks for the extra description.
> I have domain.net which is a gateway to all my services. It has buttons
> on the side for them all and then loads them in an iframe under the url
> domain.net/#Service. The services themselves are proxied by nginx at
> domain.net/service. This is Organizr if you've heard of it
> (https://github.com/causefx/Organizr).
>
> I want to force IPs outside of my LAN to access everything through
> domain.net as it has a logon to use any of the services. I only want
> direct access to domain.net/service available to my LAN.
I think I'm still not understanding the intended data flow.
It does sound like the /#Service is purely a cosmetic "overlay" on
/service, and it is still the end client that actually access /service
either way -- but in that case /#Service would be pointless, and its
login controls would be ineffective.
So I guess I am missing something.
> One more way of looking at it. When a user uses the organizr front end
> and uses a services, they get some menu bars hosted by nginx as well as
> an iframe containing domain.net/service, but it is served through
> domain.net/#Service.
"iframe" is irrelevant to nginx.
"/#Service" is irrelevant to nginx.
If the end client directly accesses /service, that is the request that
nginx will see.
The only alternative would be if the client accesses Organizr through
some url, and Organizr accesses /service on the client's behalf; in
that case, nginx will see the request to /service from Organizr, and
so nginx could block any other access to /service. (And should do so,
if Organizr is doing some form of access control.)
> When I block external IPs from domain.net/service, the iframe inside of
> domain.net/#Service also gets blocked.
I wonder, if you want to investigate this further...
without the IP block, when you use the web application normally, do
nginx logs show the requests to /service coming from the same client IP
address as the original request to /; or are they coming from a separate
Organizr address?
If you are doing any kind of "real-ip" conversion in that nginx instance,
turn it off for this logging.
> As I think through this it occurs to me I don't think the config change
> needs to be in nginx, but in organizr. I need organizr to request to
> content from a local IP. Not sure if that is possible, but I'll hit them
> up. Thanks for helping me work through it.
Good luck with it,
f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
