-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about the "group" function #6
Comments
That's aleady how it works :D you see different stuff with different ip addresses |
It looks like the trigger function is off the XFF header on the request, which makes sense. You don't always know the requestor IP if you are behind a proxy or a firewall the client IP will look like firewall or proxy, which would gum up the works. Unfortunately I can't see to even get that functionality to work properly... will keep trying :| |
As already stated in another issue is probably better to wait for the next release, which simplify the configuration. You may already build and run the next release by switching to the develop branch or wait tomorrow (maybe?) for the merge (The release is ready but not yet tested as much as I am confortable to, so might be unstable). As for the current release try to take a look at the docker-compose.nginx.yml file and the easy-gate.nginx.conf file. The confusing part is that Easy Gate itself has an instance of nginx inside the image (this is the part that has been removed from the next release), so the easy-gate.nginx.conf in that example is used to overwrite easy gate INTERNAL nginx configuration in order to accept and forward XFF.
|
Thanks @r7wx! Great project! |
Closing the issue for now due to new release b5e81c2, feel free to open if you have any questions/issues. |
to be honest, I didn't understand a lot of these comments but running easy-gate behind traefik as reverse proxy is easy-peasy, here is my docker-compose.yml if anyone is interested. No other configuration to any nginx needed. I'm trying to help out, if this is just confusing, and you probably know better, feel free to ignore it, I can live with easy-gate as is.
to debug the whole thing behind a reverse proxy I just switched the image line with this one:
and changed the target port to 80 accessing easy-gate via https://sub.domain.tld I see these headers beeing passed on to easy-gate by traefik (removed unimportant ones and masked my domain):
compare with accessing easy-gate via local IP:
so I assume the group part of easy-gate is looking at: RemoteAddr ? |
are you sure its doing that? |
Check the new version (just released) and set "behind_proxy": true in order to tell Easy Gate to check for X-Forwarded-For (if disabled it will check remote address). |
looking at the sample files, it looks like depending on how you call easy-gate you get to see different things, right?
Seems great at a first glance but looking close I figured out that I have to access easy-gate via fqdn if outside the house, use 10.10.10.x if coming through VPN and 192.168.x.y if from within my local LAN.
Would it not be better or even possible to not decide upon the method of access but upon the client IP?
This way I imagine I could always access easy-gate via fqdn and a revere proxy and depending on my client IP I would see different services?
At a first glance this seems more logical, I would only have to remember 1 address where easy-gate is running and it would automatically present me the right resources depending on my IP so if it sees my IP is a public one it'd know I'm somewhere else, seeing a 10.x range it would know I'm on the VPN and seeing 192.168.x it would know I'm on my local lan.
Is this even possible?
The text was updated successfully, but these errors were encountered: