6

I'm building a webapp, and I could use a solution that allows me to uniquely identify the users computer.

The reason for this is, that once the user is logged into to the application he/she can start several sessions (which is stored in mySQL) related to the app - however, the sessions should only be available from the computer in which the session was initiated.

I cannot use cookies, since the application should allow users to close the browser, restart the computer etc etc., without any risk of loosing the users session.

At first I thought I would be possible to get something like a motherboard serial. Naaah, not going to happen.

Then I thought of generating an MD5 hash based on users remote address + MAC address, until I found out that this is only possible using older versions of IE with ActiveX.

Then I came to think if all Chrome installations have some sort of unique browser ID I could use? ... Haven't been able to find anything helpful.

Any great ideas on how to generate an unique string based on the users computer?

CyberDude
  • 8,541
  • 5
  • 29
  • 47
EibergDK
  • 554
  • 1
  • 8
  • 19
  • possible duplicate of [How to uniquely identify a computer?](http://stackoverflow.com/questions/5048066/how-to-uniquely-identify-a-computer) – Quentin Nov 13 '12 at 07:45
  • @Quentin, Don't know why people won't use username + password to indent users...? – gdoron Nov 13 '12 at 08:08
  • Please read full post... "The reason for this is, that _____once the user is logged into to the application he/she can start several sessions____" – EibergDK Nov 13 '12 at 08:25

2 Answers2

9

You'll have to relax your constraints : even by using the browser digital print, you won't be able to have a guaranteed not changed and not lost UID.

My usual solution, which works very well but with no guarantee, is to send from the server to the browser an UID and to store it in localstorage. Note that a computer savvy user can remove it or change it. But if the user isn't your foe, this works well.

The reasons to prefer localstorage over cookies are :

  • no expiration
  • no tools to "clean" them, as they were origin-bound from the start and thus haven't the privacy-breach reputation of cookies
  • of course the cleaner and saner interface for javascript applications
Denys Séguret
  • 372,613
  • 87
  • 782
  • 758
  • 1
    Why is the `localstorage` any better than cookies? cookies will work on every browser unlike localstorage. From your MDN link: _"Storage objects are a recent addition to the standard. As such they may not be present in all browsers."_ – gdoron Nov 13 '12 at 07:47
  • [that's an old warning, nothing to worry about today](http://caniuse.com/#feat=namevalue-storage). – Denys Séguret Nov 13 '12 at 07:51
  • %8 of the internet users are something to worry about, unfortunately. the localstorage was not invented for simple tasks as this, for this cookie are the classic way. IMO, of course.\ – gdoron Nov 13 '12 at 07:54
  • They're the classic way, that is the old way but we have a cleaner and better solution now. This being said, I agree with you that cookies are a perfectly valid solution and your answer is OK. – Denys Séguret Nov 13 '12 at 07:57
  • If the user really wants to screw up the UID, that's is fine. I just need a solution, that prevents the users from accidently clearing the cookies, which then messes up the session. I'll look into your suggestion asap :) – EibergDK Nov 13 '12 at 08:19
4

I cannot use cookies, since the application should allow users to close the browser, restart the computer etc etc., without any risk of loosing the users session.

Cookies are not lost when the compute restart. You can use cookies.

gdoron
  • 147,333
  • 58
  • 291
  • 367
  • The user can delete them, though, and they are not shared across browsers and multiple user accounts. And if they are accidentally lost, it is practically impossible to recover the connection (and the data stored in that session). But for most uses, cookies should be fine. I guess we need more context. – Thilo Nov 13 '12 at 08:01
  • @Thilo. I'm not sure all those concerns are valid here. anyway if he really wants to indent a user in a bullet proof way, **User name + Password!** – gdoron Nov 13 '12 at 08:07
  • Yes, for most uses, cookies should be fine. And like you said, if the user is already logged in (with a user name), then you can link the stuff to the user account. I guess we need more context. – Thilo Nov 13 '12 at 08:08
  • Each computer needs to run some parts of app, seperate from other users/computers, using the same app can access. Cookies can be deleted - not good enough :) – EibergDK Nov 13 '12 at 08:14
  • @EibergDK. Why won't you give your users a username + password? Are you familiar with a website\app that identify without it??? – gdoron Nov 13 '12 at 08:16
  • The users are already logged into the system. I could put a sticker on each monitor with a number, and when the users wants to access to some specific function in the application, I could prompt the user for the number on the sticker. However, this allows the users to enter any number or maybe enter a wrong number. The application is a point-of-sale system, which should be able to handle multiple cash-counters - and users should be able to access any counter and therefore I do not wish to bind the user to a specific counter(computer) on login. – EibergDK Nov 13 '12 at 08:23
  • @EibergDK. Too me, it sounds like you're making a mess. – gdoron Nov 13 '12 at 08:25