Where am I ...

[Lester Caine]

Not exactly a PHP problem, but a number of my sites are now being
plagued by the fallout from it.

gethostbyaddr($_SERVER["REMOTE_ADDR"]);
Has worked perfectly for many years now, so I know exactly which Desk or
Counter is trying to log in, and I can direct announcements to the
correct location.

Some of you will already have spotted the current problem ... VDI ...
This reports a host name based on the VDI desktop accessed from the
'farm' which whilst irritating since one has to keep changing it each
day, is actually changing even during a 'session' so a caller ticket is
accessed, and can take over an hour at times to deal with, by which time
the VDI number has changed, and you can't clear the ticket :(

We can switch to manually specifying the location as part of the login
process, butit's all to easy to select the wrong Desk especially if you
were working on an adjacent one a previous day.

To my way of thinking, the IP address should be for the physical machine
that we are working with? So if the MAC address has an IP address locked
to that machine then I should be able to simply drop back to that and
ignore the host name? But I'm being told that $_SERVER["REMOTE_ADDR"]
may not be the local IP address?

Anybody got some insight into how we can get around this problem? My
particular beef with the way things are currently being run is that the
networ team seem to have no idea in the case of a suspicious access
attempt even which building the offender is located let alone what desk,
and I can't believe that is acceptable security practice?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

[Robert Cummings]

Post by Lester Caine
Not exactly a PHP problem, but a number of my sites are now being
plagued by the fallout from it.
gethostbyaddr($_SERVER["REMOTE_ADDR"]);
Has worked perfectly for many years now, so I know exactly which Desk or
Counter is trying to log in, and I can direct announcements to the
correct location.
Some of you will already have spotted the current problem ... VDI ...
This reports a host name based on the VDI desktop accessed from the
'farm' which whilst irritating since one has to keep changing it each
day, is actually changing even during a 'session' so a caller ticket is
accessed, and can take over an hour at times to deal with, by which time
the VDI number has changed, and you can't clear the ticket :(
We can switch to manually specifying the location as part of the login
process, butit's all to easy to select the wrong Desk especially if you
were working on an adjacent one a previous day.
To my way of thinking, the IP address should be for the physical machine
that we are working with? So if the MAC address has an IP address locked
to that machine then I should be able to simply drop back to that and
ignore the host name? But I'm being told that $_SERVER["REMOTE_ADDR"]
may not be the local IP address?
Anybody got some insight into how we can get around this problem? My
particular beef with the way things are currently being run is that the
networ team seem to have no idea in the case of a suspicious access
attempt even which building the offender is located let alone what desk,
and I can't believe that is acceptable security practice?

Is this a proxy issue? If so, have you tried: HTTP_X_FORWARDED_FOR and
then fall back on REMOTE_ADDR if it isn't set?

Cheers,
Rob.
--
Phone: [phone] +++ Cell: 613-600-2836
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.

[Ashley Sheridan]

I've had this before on a load balanced environment, and the original ip was being stuffed into another (custom) header (can't remember what just now)

Post by Lester Caine
Not exactly a PHP problem, but a number of my sites are now being
plagued by the fallout from it.
gethostbyaddr($_SERVER["REMOTE_ADDR"]);
Has worked perfectly for many years now, so I know exactly which Desk or
Counter is trying to log in, and I can direct announcements to the
correct location.
Some of you will already have spotted the current problem ... VDI ...
This reports a host name based on the VDI desktop accessed from the
'farm' which whilst irritating since one has to keep changing it each
day, is actually changing even during a 'session' so a caller ticket is
accessed, and can take over an hour at times to deal with, by which time
the VDI number has changed, and you can't clear the ticket :(
We can switch to manually specifying the location as part of the login
process, butit's all to easy to select the wrong Desk especially if you
were working on an adjacent one a previous day.
To my way of thinking, the IP address should be for the physical machine
that we are working with? So if the MAC address has an IP address locked
to that machine then I should be able to simply drop back to that and
ignore the host name? But I'm being told that $_SERVER["REMOTE_ADDR"]
may not be the local IP address?
Anybody got some insight into how we can get around this problem? My
particular beef with the way things are currently being run is that the
networ team seem to have no idea in the case of a suspicious access
attempt even which building the offender is located let alone what desk,
and I can't believe that is acceptable security practice?

Thanks,
Ash

[Aziz Saleh]

Post by Ashley Sheridan
I've had this before on a load balanced environment, and the original ip
was being stuffed into another (custom) header (can't remember what just
now)

Post by Lester Caine
Not exactly a PHP problem, but a number of my sites are now being
plagued by the fallout from it.
gethostbyaddr($_SERVER["REMOTE_ADDR"]);
Has worked perfectly for many years now, so I know exactly which Desk or
Counter is trying to log in, and I can direct announcements to the
correct location.
Some of you will already have spotted the current problem ... VDI ...
This reports a host name based on the VDI desktop accessed from the
'farm' which whilst irritating since one has to keep changing it each
day, is actually changing even during a 'session' so a caller ticket is
accessed, and can take over an hour at times to deal with, by which time
the VDI number has changed, and you can't clear the ticket :(
We can switch to manually specifying the location as part of the login
process, butit's all to easy to select the wrong Desk especially if you
were working on an adjacent one a previous day.
To my way of thinking, the IP address should be for the physical machine
that we are working with? So if the MAC address has an IP address locked
to that machine then I should be able to simply drop back to that and
ignore the host name? But I'm being told that $_SERVER["REMOTE_ADDR"]
may not be the local IP address?
Anybody got some insight into how we can get around this problem? My
particular beef with the way things are currently being run is that the
networ team seem to have no idea in the case of a suspicious access
attempt even which building the offender is located let alone what desk,
and I can't believe that is acceptable security practice?

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

There are a couple of server variables you can check for the IP you want:

HTTP_CLIENT_IP
HTTP_X_FORWARDED_FOR
REMOTE_ADDR

The following are not usually used, but I did see them used on several
systems:

HTTP_X_FORWARDED
HTTP_FORWARDED_FOR
HTTP_FORWARDED
HTTP_X_CLUSTER_CLIENT_IP

If none of the above work, consult your proxy or switch manual, hopefully
they have followed industrial standards and one of the above does work,

[Lester Caine]

Post by Aziz Saleh
HTTP_CLIENT_IP
HTTP_X_FORWARDED_FOR
REMOTE_ADDR
The following are not usually used, but I did see them used on several
HTTP_X_FORWARDED
HTTP_FORWARDED_FOR
HTTP_FORWARDED
HTTP_X_CLUSTER_CLIENT_IP
If none of the above work, consult your proxy or switch manual,
hopefully they have followed industrial standards and one of the above
does work,

OK this is an intranet system, and the reason I'm asking is because I
have no access to the setup of the network. Heck I'm not even sure WHICH
VDI system the site is using and my contacts in IT support can't answer
questions I am asking, so what I'm currently trying to do is establish
where to start looking. Up until now all the sites have used IE
exclusively, but now Chrome has appeared on the list, which is strange
when *I* am not allowed to use that when using remote access :)

The web server that is feeding my application is Apache2 on one of my
own machines, so I have control over that side, but not the browser side
machines which are what are currently on a mixture of 'real' machines
and thin clients. So I need to try and find a solution that co-exists ...

I will see if I can get access to a remote VDI desktop as currently I'm
still working on a terminal services one via the citrix remote access -
but I don't use that much anyway as I have VNC direct to all of my own
machines ...
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk