Controlling Access on and off LAN

[Francis Daly]

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 at daoine.org