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?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Sep 17, 2008, at 957PM, 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?
I saw the same thing on my OS X box, and decided to disable IPV6 for
now. Edit httpd.conf and change: "Listen 80" to "Listen 0.0.0.0:80"
and when you restart Apache it'll always return 127.0.0.1
Brady
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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
>
Thanx, using the real ip addr solved my problem as far as my test
install is concerned. I did do some research and found the text display
conventions for IPv6 ip addresses. But it looks like it would be better
to develop a better test than to make an IPv6 safe one.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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