Here is another problem i have a login system, i want to target their account to only 1 computer so they cannot change where they access it from, I know IP address isnt practical as if it had DSL, and dynamic, it will change IP each time, is there anyway, when they login, i can read the CPUS, ID NUMBER, or what phone number they are dialing in from, and store that each time, and when they try loggin in elese, where it will give them an error, any thoughts?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PHONE NUMBER CODING
- Thread starter V10Viper
- Start date
There is no way that you can get the "CPU id number" or the telephone number that they are dialing up through using Javascript. And rightly so I might add.
In response to your requests for thoughts... I would suggest you tie the login process to their email address and require they provide that (and some secret password that they choose) every time they log in. Just like the method used on countless websites all over the world.
Jeff
In response to your requests for thoughts... I would suggest you tie the login process to their email address and require they provide that (and some secret password that they choose) every time they log in. Just like the method used on countless websites all over the world.
Jeff
- Thread starter
- #3
There is no way you can do what you want to do. It cannot be done using Javascript. The closest you could come is to set a cookie on their system and check for that cookie presence/content when they connect. This is fraught with holes as users can delete cookies or block them.
Jeff
Jeff
I'm going to have to agree with Jeff... limiting a user to a specific machine kinda defeats the idea of using the internet for research and data exchange. It's the same as saying you can only make a telephone call from a specific telephone. A username/password makes so much more sense.
There's always a better way. The fun is trying to find it!
There's always a better way. The fun is trying to find it!
Try this function, it will give you thier Login Name, Computer Name and Domain. One catch thou... they will get a pop up box indicating that an ActiveX controller will start, if they click on no/cancel then you will not get any info back.
I left the alert for you to test, but you can remove it and assign the values as you please.
function getUserInfo()
{
var wshNetwork = new ActiveXObject("WScript.Network")
alert("Username: \t" + wshNetwork.UserName + "\n"
+ "Computer Name: \t" + wshNetwork.ComputerName + "\n"
+ "Domain: \t\t" + wshNetwork.Domain + "\n")
}
I left the alert for you to test, but you can remove it and assign the values as you please.
function getUserInfo()
{
var wshNetwork = new ActiveXObject("WScript.Network")
alert("Username: \t" + wshNetwork.UserName + "\n"
+ "Computer Name: \t" + wshNetwork.ComputerName + "\n"
+ "Domain: \t\t" + wshNetwork.Domain + "\n")
}
- Thread starter
- #8
BillyRayPreachersSon
Programmer
Suggest you read up on server-side coding.
Dan
- Thread starter
- #11
Using javascript is definately not the way to do this - javascript can be turned off by the user. Better to build the entire script in a server-side language like PHP or PERL. You can still place and read a cookie in the user's machine like javascript and would be the place to log the user's phone number. From there, you can match the login with the cookie data. Of course, you'd have to rely on the user entering the correct data to place in the cookie. But this presents another problem... what if the user had a broadband connection instead of dial-up? No phone number.
And then what are your plans if they try to access your site from another computer? (No cookie stored there.) Are you going to deny them access completely or have them enter the data again so you can store a cookie on that machine? Not too much of a problem but now the user has access from 2 machines - something you didn't want in the first place. This would then lead to a 3rd, 4th, or even a 5th PC that a single user access your site from.
You could take the hard line and tell the user that they must access your pages from just one computer but I doubt that they'll be too anxious to return to your site.
Maybe it's just better to ask for a username and password instead and forget the whole cookie business?
There's always a better way. The fun is trying to find it!
And then what are your plans if they try to access your site from another computer? (No cookie stored there.) Are you going to deny them access completely or have them enter the data again so you can store a cookie on that machine? Not too much of a problem but now the user has access from 2 machines - something you didn't want in the first place. This would then lead to a 3rd, 4th, or even a 5th PC that a single user access your site from.
You could take the hard line and tell the user that they must access your pages from just one computer but I doubt that they'll be too anxious to return to your site.
Maybe it's just better to ask for a username and password instead and forget the whole cookie business?
There's always a better way. The fun is trying to find it!
How are you going to get this number in the first place. You cannot. Nor can you get the Machine CPU "id" - both requirements for this solution. I've already been down the cookie route with V10Viper... but he seems to just ignore my posts. *shrug*
Jeff
Jeff,
My intention, although not entirely clear, was for V10viper to provide a form for the user to enter this data:
The point I was really trying to make was that unless this is an intranet and the users are required to use a specific machine, then trying to restrict a user to access from a single machine would be a very good way of driving them away from the site.
There's always a better way. The fun is trying to find it!
My intention, although not entirely clear, was for V10viper to provide a form for the user to enter this data:
.
The point I was really trying to make was that unless this is an intranet and the users are required to use a specific machine, then trying to restrict a user to access from a single machine would be a very good way of driving them away from the site.
There's always a better way. The fun is trying to find it!
Ah, I see what you were saying.
You know... even with our intranet it's sometimes a struggle keeping users coming back! It seems that sometimes, no matter what you do, it's always "your fault" when a page doesn't do what they want it to do (and some of the requests for functionality are rather far fetched).
They haven't seen a 2 page terms and conditions page that they will have to agree to every time they log in *lol*
Jeff
You know... even with our intranet it's sometimes a struggle keeping users coming back! It seems that sometimes, no matter what you do, it's always "your fault" when a page doesn't do what they want it to do (and some of the requests for functionality are rather far fetched).
They haven't seen a 2 page terms and conditions page that they will have to agree to every time they log in *lol*
Jeff
V10Viper,
The internet isn't built like that. It's based on IPs, and you already determined the problem with identifying someone by IP... the one you see might not be the end of the line, but rather a router or firewall. Not being able to, or caring to, know the exact route to an individual machine is a *good thing*. That's the whole point of IP... there are multiple routes, and each packet picks the most efficient... if one path is cutoff (original ARPA reason being a nuke), then it finds a different path. This is what makes it better than a switched system like the POTS (plain old telephone service).
The only way to authenticate someone is to ask them something only they could know. Usually through the web, servers identiy clients via username/password, and clients identify servers via SSL public-key encryption (the server knows a private key). The reason for this difference between client and server authentication is that the server-side is expected to be automated, while the client-side is expected to be interactive.
It sounds like you want the client side to be automated as well. Then the best solution is to use public-key encryption. You would ask your users to create a public/private key pair, save the private key on their computer, and send you the public key. Then when they log on, you would authenticate them via SSL. This is done by sending them a message encrypted with their public key... they decrypt it with their private key, and send you the result encrypted with your public key. If, after you decrypt it with your private key, the message matches the one you sent, then their system is authentic (or they allowed their key to be stolen). This is all automated of course by the software.
You still can't authenticate their individual machine though, as they can copy their private key to another computer and still authenticate. Being able to interact with their machine only and not the user isn't currently possible, as the user has complete control over the machine. They can know anything it knows, and change it.
What you're asking for won't be possible unless/until "Trusted Computing" (such as Palladium) becomes universal. Then there will be a hardware or BIOS digital signature embedded in each computer which cannot be changed by the owner of that computer. External software will then be able to determine the user-independent identification of a computer system, no matter how many layers of IP it is hiding behind. This is being proposed by the DRM Nazis so that it'll be impossible to pirate software and so that computers can be identified anywhere on the internet in order to press charges against downloaders. This means that people will have to unregister software/songs/etc from one computer and re-register them on another before transferring their "rights" from one to another. This of course flies in the face of copyright law, and I shudder to imagine living under such a police state, but it may someday happen, and then you'll be able to do what you want.
Sincerely,
Tom Anderson
Order amid Chaos, Inc.
The internet isn't built like that. It's based on IPs, and you already determined the problem with identifying someone by IP... the one you see might not be the end of the line, but rather a router or firewall. Not being able to, or caring to, know the exact route to an individual machine is a *good thing*. That's the whole point of IP... there are multiple routes, and each packet picks the most efficient... if one path is cutoff (original ARPA reason being a nuke), then it finds a different path. This is what makes it better than a switched system like the POTS (plain old telephone service).
The only way to authenticate someone is to ask them something only they could know. Usually through the web, servers identiy clients via username/password, and clients identify servers via SSL public-key encryption (the server knows a private key). The reason for this difference between client and server authentication is that the server-side is expected to be automated, while the client-side is expected to be interactive.
It sounds like you want the client side to be automated as well. Then the best solution is to use public-key encryption. You would ask your users to create a public/private key pair, save the private key on their computer, and send you the public key. Then when they log on, you would authenticate them via SSL. This is done by sending them a message encrypted with their public key... they decrypt it with their private key, and send you the result encrypted with your public key. If, after you decrypt it with your private key, the message matches the one you sent, then their system is authentic (or they allowed their key to be stolen). This is all automated of course by the software.
You still can't authenticate their individual machine though, as they can copy their private key to another computer and still authenticate. Being able to interact with their machine only and not the user isn't currently possible, as the user has complete control over the machine. They can know anything it knows, and change it.
What you're asking for won't be possible unless/until "Trusted Computing" (such as Palladium) becomes universal. Then there will be a hardware or BIOS digital signature embedded in each computer which cannot be changed by the owner of that computer. External software will then be able to determine the user-independent identification of a computer system, no matter how many layers of IP it is hiding behind. This is being proposed by the DRM Nazis so that it'll be impossible to pirate software and so that computers can be identified anywhere on the internet in order to press charges against downloaders. This means that people will have to unregister software/songs/etc from one computer and re-register them on another before transferring their "rights" from one to another. This of course flies in the face of copyright law, and I shudder to imagine living under such a police state, but it may someday happen, and then you'll be able to do what you want.
Sincerely,
Tom Anderson
Order amid Chaos, Inc.
- Status
Similar threads
- Locked
- Question