Hello,
I want to find each LAN connected computer separately. I am fetching ip address but i am assuming if many computers are connected to LAN they may give same ip.How can i differentiate all computers separately in php ?
A:
You can't. The only thing would be to use sessions (i.e. cookies) to differentiate them, but that's not a safe way.
poke
2010-10-27 13:50:11
Not safe how? Sure, sessions by cookies can be copied if sniffed, but that's what HTTPS is for. Sure, there are other ways to get crap off the machine itself, but you have to rely on something...
Brad
2010-10-27 14:10:45
Not safe as in you cannot be sure that the session cookie you read out really identifies the one user you expect; and as OP seems to try to separate users by their physical machine, you can also never be sure that a different session means a different machine. And actually one shouldn't separate users based by their IP, host or whatever; it's the user that is important, not the thing/location they are using to connect.
poke
2010-10-27 21:52:40
Not true. If two machines are behind a NAT they will appear as the same address to the web server.
speshak
2010-10-27 13:52:11
speshak is right, additionaly: you can't get the clients mac-adress in a php-script.
oezi
2010-10-27 13:54:38
I am using php_curl for remote server script sharing.I think cookies concept will not be very comfortable for this.MAC-Address i was assumed can it fetch MAC address in php ?
Ajay_kumar
2010-10-27 13:59:25
+1
A:
easiest and best way: use phps session-management - every client is given an id, stored in a cookie (if enabled) or given as a get-variable on every link and form. (alternatively you could set a cookie on your own)
identifying every client by ip is a bad idea and won't work. clients that use the same router will have the same ip's - clients connected through a proxy-pool could have another ip with every page load.
EDIT: if you need a solution that can't be manipulated by the client in an easy way, try to do a combination of those, using all that are supported by the clients browser and compare them on each page-load:
- "normal" HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in and reading out Web History
- Storing cookies in HTTP ETags
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
oezi
2010-10-27 13:52:35
Don't use such browser-specific methods (HTML5 included for now) for this. It isn't worth your time, unless you have a specific situation where you know what your clients will be running, such as an intranet. Even then... this really is all academic and not a good idea. Stick to sessions, like oezi originally said.
Brad
2010-10-27 14:13:22
oezi
2010-10-27 14:16:41
oezi, yeah but you have to do different things to win different situations.
jack
2010-10-27 14:39:27
Session management by default identifies the session - not the computer. Even using Cookies with long expiration would only be specific to the user at that computer. There is no way to accurately differentiate between computers at a remote network (but maybe the OP didn't really mean that)
symcbean
2010-10-27 16:11:43
@symcbean: i never wrote sessions identify the computer - sorry if my post is a bit ambiguous in that way, my english isn't the very best and sometimes i'm missing the words toll tell exactly what i want to say. but: if you want and need to identify a _computer_, you _could_ use the options in my edit - flash-cookies for example are shared between browsers, so it will be the same cookie even if the browser changes... a 100% perfect and reliable way to identify a computer doesn't exist, but with a combination of all possibilitys, your chances aren't that bad.
oezi
2010-10-27 16:18:18
@oezi: your post was not ambiguous and I didn't mean to cast any aspersions - the original question was how to differentiate between computers - I was trying to highlight that there was no practical solution to the original question and clarify that your answer did not deal with that case.
symcbean
2010-10-28 16:37:47