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
