IP whitelisting is not possible from host server about polydeploy

[bdukes]

In https://github.com/cantarus/PolyDeploy/blob/78b6127ae1ea8200c8ef1ea233ac6b0d84461535/PolyDeploy/Components/WebAPI/ActionFilters/InWhitelist.cs#L46, consider using HttpRequestBase.IsLocal instead of checking 127.0.0.1

@tomwalters It's not a reverse proxy issue, PolyDeploy has handling for this already built in.

The scenario this occurred in was where the web server had multiple IP addresses bound to it. So it appeared the traffic was coming from one of those rather than the localhost loopback address.

[RichardHowells]

The scenario this occurred in was where the web server had multiple IP addresses bound to it. So it appeared the traffic was coming from one of those rather than the localhost loopback address.

I just installed v0.9.3

I found the same problem as mentioned above on a machine with multiple IP addresses. It is no longer easy to hack IP addresses into the database as they are no longer stored in human readable form.

I used the following workaround, which is somewhat complex and a PITA...

• Add another IIS binding for https://127.0.0.1
• Add a portalalias for https://127.0.0.1

Then I was able to get to the site using 127.0.0.1 and access the UI for setting up WhiteLists and API Keys.

The machine I am using has multiple installs of DNN and most of the installs have multiple portals. In this situation my workaround is fairly painful.

@can-anierzad - did the change you refer to actually get made? If so it does not seem to help in my situation.

[tomwalters]

@can-martin-kennish This is likely caused because the server is behind a reverse proxy, thus obscuring the real IP. Is there a way we could inspect the headers to extract an X-Forwarded-For?

There might be some security considerations to make around IP spoofing when doing a direct comparison to 127... so the solution from @bdukes is probably the best bet (although I wouldn't be surprised if the actual implementation is exactly the same.)

[bdukes]

The basic logic for IsLocal is in HttpWorkerRequest

Thanks @bdukes, I'll make the change and see if it resolves the issue we're having in the environment @can-martin-kennish described above.