Re: $_SERVER["REMOTE_ADDR"] returning ::1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please keep the discussion on the list.

On 7 Oct 2008, at 06:11, David Rocks wrote:
Your work around worked fine for me but I just had some time to revisit this and wanted to see how hard it would be to rewrite this test. But I ran into a question. The test that was failing compared the clients IP address. It looks like transparent proxies are used for caching web server pages and shouldn't affect this test. I saw the problem because I was accessing the web server locally via localhost. What technology would raise the possibility that a remote clients IP address wouldn't be the same from one access of the web server to another?

Proxies do not necessarily cache web pages - this is an optional feature of the technology. At the most basic level in most implementations they provide a protected bridge between two networks.

Proxies can be implemented as shared clusters such that any request going through the cluster could appear to come from one of a number of IPs (i.e. the client is not tied to a single proxy appliance). In this instance you cannot rely on a client always coming from the same IP.

In addition it's pretty standard practice for a lot of ISPs to have relatively short leases on their IP pool. This means that a client could move between different IPs between requests. This is unlikely however because I believe most ISPs will do everything they can to issue a connection with the same IP when the lease expires but it's not something you can rely on.

In any case you cannot rely on the user not disconnecting their laptop from a wired connection and then connecting to a wireless connection that runs through a different router. This would also change their IP.

At the end of the day it's well understood that IP addresses should not be used for authentication or continuity purposes. I've not come across a session implementation that uses them for a very long time.

-Stut

--
http://stut.net/

Stut wrote:
On 18 Sep 2008, at 16:37, David Rocks wrote:
Stut wrote:
On 18 Sep 2008, at 05:57, David Rocks wrote:
I am running a test PHP web app on my local machine that uses REMOTE_ADDR and most of the time ::1 is returned as the IP addr and sometimes it is 127.0.0.1 . I am on OS X 10.5.5 and using APACHE 2. PHPINFO always returns ::1 for REMOTE_ADDR. Is this a PHP or a APACHE 2 thing?
It's coming from Apache and is correct. ::1 is the same as 127.0.0.1 in IPv6. Which you get will depend on how you request the page and how your DNS/hosts file is set up. Request it with an IPv6 domain/IP and REMOTE_ADDR will also be IPv6. You should be able to disable IPv6 in your system settings, but from a future-proof point of view you should be able to handle both.
-Stut
This app uses this test to insure that the page being processed came from the same machine as was used to login to the app. The app is intended for broad use so I can't control the use of IPv6. Is localhost the only case where the value returned might have different values? Can you point to a reference where I might figure out a better future proof test?

Using the IP is not a reliable way to check for this. Some ISPs use transparent proxies which can cause each subsequent request to come from a different IP, regardless of whether it's v4 or v6. You'd be better off using a cookie, although that would be a bit less secure.

If you really need to use IP then you can probably rely on it not switching between v4 and v6 if you're not using localhost. For testing use the machine's real IP or hostname instead of localhost and this problem should disappear.

-Stut



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux