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