Authentication premission to software [modified]
-
We have done one project(software).we are giving our software to our clients.Now we are deploying our software in client server system.But they are asking permission for 10 systems only.We want to resit for 10 systems only. Eg:We are deploying software in our client server system.They are having 50 systems.But they have use our software for 10 systems at a time.If any 11th person will want to enter he should get one message like room is full.If any one from 10 system is Logout then other person can enter. How to do this application. New Q: You u not getting me.At a time our client's should use our software in 10 system.while use the 10 system no other(11 person) should not login .If any person from 10 systems is logout,then only 11person can login from person who was logout. thank's in adv M.lavan
modified on Friday, February 20, 2009 3:28 AM
Does your application use a central database? If so simply have a login table, add 1 when a user logs in and subtract1 when they log out. Check the count before allowing a login. Personally I would actually keep a record of login/out with user name and times.
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP
-
We have done one project(software).we are giving our software to our clients.Now we are deploying our software in client server system.But they are asking permission for 10 systems only.We want to resit for 10 systems only. Eg:We are deploying software in our client server system.They are having 50 systems.But they have use our software for 10 systems at a time.If any 11th person will want to enter he should get one message like room is full.If any one from 10 system is Logout then other person can enter. How to do this application. New Q: You u not getting me.At a time our client's should use our software in 10 system.while use the 10 system no other(11 person) should not login .If any person from 10 systems is logout,then only 11person can login from person who was logout. thank's in adv M.lavan
modified on Friday, February 20, 2009 3:28 AM
The logic for keeping track of who is logged in, preventing multiple simultaneous logins by the same user (if desired), and denying login for an 11th user is straightforward. But presumably you would like to avoid hard-coding this yet add some sort of protection so users cannot too easily get around the restrictions. My suggestion is to use a license file in flat or XML format and sign it digitally. Digital signatures work similarly to public-key encryption (and indeed one normally uses the same keys for signing and encryption purposes). Basically, there is a key pair consisting of a private key used for decryption and signing, and a public key which is used for encryption and verifying signatures. This is handy, because it means you can embed the public key in your application to verify that the license file has indeed been signed by the corresponding private key, which you don't have to distribute. I can make you - for a reasonable fee - a license class that takes care of the details of signing a license. Then you simply create your key pair (using sn.exe, provided with Visual Studio), and focus on the business logic rather than the tech details. The class will represent the license as a collection of name-value pairs, keep the file in plain text so it can be read by a human, but detect it if the file is modified so the information no longer matches the signature. Just message me if you are interested.
-
The logic for keeping track of who is logged in, preventing multiple simultaneous logins by the same user (if desired), and denying login for an 11th user is straightforward. But presumably you would like to avoid hard-coding this yet add some sort of protection so users cannot too easily get around the restrictions. My suggestion is to use a license file in flat or XML format and sign it digitally. Digital signatures work similarly to public-key encryption (and indeed one normally uses the same keys for signing and encryption purposes). Basically, there is a key pair consisting of a private key used for decryption and signing, and a public key which is used for encryption and verifying signatures. This is handy, because it means you can embed the public key in your application to verify that the license file has indeed been signed by the corresponding private key, which you don't have to distribute. I can make you - for a reasonable fee - a license class that takes care of the details of signing a license. Then you simply create your key pair (using sn.exe, provided with Visual Studio), and focus on the business logic rather than the tech details. The class will represent the license as a collection of name-value pairs, keep the file in plain text so it can be read by a human, but detect it if the file is modified so the information no longer matches the signature. Just message me if you are interested.
dojohansen wrote:
My suggestion is to use a license file in flat or XML format and sign it digitally
I may be missing something, but if the licence file is distributed with the application how will it prevent more than x concurrent users, which is what the OP was getting at? The only way I know of to prevent more than a given number (say 10) of concurrent users is to have a central 'register' of currently logged in users. By including the user name etc if required you can display a list of current users (so the 11th person could see if anyone could log out). The actual number of allowed users can be stored as an encrypted value, so the chances of it being changed to another value are slim. As an extra check, you can validate the user is still logged in before allowing functionality.
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP
-
dojohansen wrote:
My suggestion is to use a license file in flat or XML format and sign it digitally
I may be missing something, but if the licence file is distributed with the application how will it prevent more than x concurrent users, which is what the OP was getting at? The only way I know of to prevent more than a given number (say 10) of concurrent users is to have a central 'register' of currently logged in users. By including the user name etc if required you can display a list of current users (so the 11th person could see if anyone could log out). The actual number of allowed users can be stored as an encrypted value, so the chances of it being changed to another value are slim. As an extra check, you can validate the user is still logged in before allowing functionality.
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP
You are indeed missing something: The point. As I wrote, counting the number of users and taking action in the application according to what license has been bought is fairly straightforward. The challenge in making an application enforce license options is not this code, but how to make licensing flexible without making it easy to circumvent restrictions (hard-coding limitations simply means you must build the application for each combination of options you offer, and requires a complete deployment operation to change the license options, e.g. by upselling). You suggest storing this information (number of allowed users, i.e. the license data) as an encrypted number. Doing so would make it harder to cheat, but is not secure because you now need to store the encryption key securely. The advantage of using signatures is that they are verified using the PUBLIC key, so everything - the signature and the key and the license data - can be kept in human-readable clear text form without compromising the integrity of the system. How would you suggest storing the decryption key for your proposed implementation?
-
We have done one project(software).we are giving our software to our clients.Now we are deploying our software in client server system.But they are asking permission for 10 systems only.We want to resit for 10 systems only. Eg:We are deploying software in our client server system.They are having 50 systems.But they have use our software for 10 systems at a time.If any 11th person will want to enter he should get one message like room is full.If any one from 10 system is Logout then other person can enter. How to do this application. New Q: You u not getting me.At a time our client's should use our software in 10 system.while use the 10 system no other(11 person) should not login .If any person from 10 systems is logout,then only 11person can login from person who was logout. thank's in adv M.lavan
modified on Friday, February 20, 2009 3:28 AM
Well obviously it is not possible unless the systems have some means of communication. So based on no more information than "they have 10 systems" it's not really possible to give useful advice. Among the numerous potential solutions, the processes could communicate via: - remoting - sockets - web services - accessing a common database - sattelite link - gsm modem - fm radio and many many others. But there is no magic dust that you can sprinkle on just *any* type of system and have it suddenly communicate with other systems that resemble itself. At least not that I know of.
-
You are indeed missing something: The point. As I wrote, counting the number of users and taking action in the application according to what license has been bought is fairly straightforward. The challenge in making an application enforce license options is not this code, but how to make licensing flexible without making it easy to circumvent restrictions (hard-coding limitations simply means you must build the application for each combination of options you offer, and requires a complete deployment operation to change the license options, e.g. by upselling). You suggest storing this information (number of allowed users, i.e. the license data) as an encrypted number. Doing so would make it harder to cheat, but is not secure because you now need to store the encryption key securely. The advantage of using signatures is that they are verified using the PUBLIC key, so everything - the signature and the key and the license data - can be kept in human-readable clear text form without compromising the integrity of the system. How would you suggest storing the decryption key for your proposed implementation?
dojohansen wrote:
You are indeed missing something: The point.
I think I am somewhere. Can you explain a bit more what you mean? I am, genuinely, puzzled by how, having a licence file which is distributed with your application, can limit the number of concurrent users. Or have I misunderstood what you meant?
dojohansen wrote:
How would you suggest storing the decryption key for your proposed implementation?
The application would have the key to decrypt the number, obviously. And yes, I know this could be reverse engineered, but if you use obfusication etc its relatively safe from most casual users. Its all down to how valuable your application is.
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP
-
dojohansen wrote:
You are indeed missing something: The point.
I think I am somewhere. Can you explain a bit more what you mean? I am, genuinely, puzzled by how, having a licence file which is distributed with your application, can limit the number of concurrent users. Or have I misunderstood what you meant?
dojohansen wrote:
How would you suggest storing the decryption key for your proposed implementation?
The application would have the key to decrypt the number, obviously. And yes, I know this could be reverse engineered, but if you use obfusication etc its relatively safe from most casual users. Its all down to how valuable your application is.
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP
Dear Bob,
Ashfield wrote:
Can you explain a bit more what you mean? I am, genuinely, puzzled by how, having a licence file which is distributed with your application, can limit the number of concurrent users. Or have I misunderstood what you meant?
You may feel that your intellect is of such an unrivalled caliber that no further contributions from other people could possibly add anything to what you have to say. I may feel differently. Right from the start, I made it clear that I consider there is one part of implementing license solutions that is tricky, and that is to ensure the integrity of the license information. I then provided an elegant solution to this problem. I don't know if it was exactly what the OP had in mind, but it surely is related to implementing a licensing system and as such potentially useful. I'll let the OP choose whether or not he wishes to use my input, and if I didn't address his issue precisely then relatively little damage was done. His issue wasn't very clearly defined, at least not to me, and to be honest I have some serious doubts as to how useful your own contribution is to the OP. Perhaps you shouldn't throw stones when in a glass house.
Ashfield wrote:
I know this could be reverse engineered, but if you use obfusication etc its relatively safe from most casual users
I am curious to know what makes you elevate this to a better solution than using digital signatures - apart from the fact that it was you who suggested it - since you seem to understand that it would not be secure, and it offers absolutely no advantages to compensate for this drawback when compared to using signatures. I will suggest a possible explanation: your ego does not allow you to ever face up to the fact that you aren't necessarily the most brilliant person in the universe - but this is of course just speculation on my part.
Ashfield wrote:
Its all down to how valuable your application is.
Actually, it isn't - rather, it's down to how important it is to make sure the application can enforce license options. An application may well be very valuable without extensive protection - for proof, consider the two most valuable pieces of software ever written (for the owner anyway), Windows and Office, until very recently. Also, even if strong protection is not necessary, a more complicated solution that is less secure do
-
Dear Bob,
Ashfield wrote:
Can you explain a bit more what you mean? I am, genuinely, puzzled by how, having a licence file which is distributed with your application, can limit the number of concurrent users. Or have I misunderstood what you meant?
You may feel that your intellect is of such an unrivalled caliber that no further contributions from other people could possibly add anything to what you have to say. I may feel differently. Right from the start, I made it clear that I consider there is one part of implementing license solutions that is tricky, and that is to ensure the integrity of the license information. I then provided an elegant solution to this problem. I don't know if it was exactly what the OP had in mind, but it surely is related to implementing a licensing system and as such potentially useful. I'll let the OP choose whether or not he wishes to use my input, and if I didn't address his issue precisely then relatively little damage was done. His issue wasn't very clearly defined, at least not to me, and to be honest I have some serious doubts as to how useful your own contribution is to the OP. Perhaps you shouldn't throw stones when in a glass house.
Ashfield wrote:
I know this could be reverse engineered, but if you use obfusication etc its relatively safe from most casual users
I am curious to know what makes you elevate this to a better solution than using digital signatures - apart from the fact that it was you who suggested it - since you seem to understand that it would not be secure, and it offers absolutely no advantages to compensate for this drawback when compared to using signatures. I will suggest a possible explanation: your ego does not allow you to ever face up to the fact that you aren't necessarily the most brilliant person in the universe - but this is of course just speculation on my part.
Ashfield wrote:
Its all down to how valuable your application is.
Actually, it isn't - rather, it's down to how important it is to make sure the application can enforce license options. An application may well be very valuable without extensive protection - for proof, consider the two most valuable pieces of software ever written (for the owner anyway), Windows and Office, until very recently. Also, even if strong protection is not necessary, a more complicated solution that is less secure do
Please accept my apologies if you feel I am trying in some way to denigrate your replies, I'm not. I am probably was not very clear in what I meant, I have just not grasped what you mean. I assume (and this is probably where I am wrong) that each installation (i.e. on each PC) there is a copy of the app and a digitally signed licence file. I'm with you to there. Now the bit where I am lost, and you seem to have taken offence at - does this somehow limit the number of users, or is that not part of what you are talking about? I know you said originally about limiting the number of users to be easy (or words to that effect), is the bit about licences more of an insight into a way of securing your app?
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP
-
Please accept my apologies if you feel I am trying in some way to denigrate your replies, I'm not. I am probably was not very clear in what I meant, I have just not grasped what you mean. I assume (and this is probably where I am wrong) that each installation (i.e. on each PC) there is a copy of the app and a digitally signed licence file. I'm with you to there. Now the bit where I am lost, and you seem to have taken offence at - does this somehow limit the number of users, or is that not part of what you are talking about? I know you said originally about limiting the number of users to be easy (or words to that effect), is the bit about licences more of an insight into a way of securing your app?
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP
Ashfield wrote:
Please accept my apologies
Accepted. If I misinterpreted you, I apologize for retorting!
Ashfield wrote:
I assume that each installation (i.e. on each PC) there is a copy of the app and a digitally signed licence file.
Relatively little is known about the mysterious "systems" - whether it is clients or servers or complete client-server installations that is meant - so I for one don't know how to help with that. If you notice my other post I'm trying to make the point there that the key is to figure out how the systems can communicate, and we have no way of knowing based on what's provided so far by the OP. So you're absolutely right, if maybe needlessly sarcastic, that putting a license file, signed or not, onto the computers will not automatically restrict the number of users logged on. So that is indeed not part of what I am talking about. In our own case, we restrict the number of users that can be simultaneously logged on to any given database, and the code required is very simple since obviously all the apps (web apps in a farm, typically) can share information in the database. I guess I couldn't quite believe that the poster would be asking about how the systems can communicate without saying more about it, so I assumed the real problem was a more general "how can we make such a thing as a license system?" and rolled out from there. Peace & Love... :D
-
Ashfield wrote:
Please accept my apologies
Accepted. If I misinterpreted you, I apologize for retorting!
Ashfield wrote:
I assume that each installation (i.e. on each PC) there is a copy of the app and a digitally signed licence file.
Relatively little is known about the mysterious "systems" - whether it is clients or servers or complete client-server installations that is meant - so I for one don't know how to help with that. If you notice my other post I'm trying to make the point there that the key is to figure out how the systems can communicate, and we have no way of knowing based on what's provided so far by the OP. So you're absolutely right, if maybe needlessly sarcastic, that putting a license file, signed or not, onto the computers will not automatically restrict the number of users logged on. So that is indeed not part of what I am talking about. In our own case, we restrict the number of users that can be simultaneously logged on to any given database, and the code required is very simple since obviously all the apps (web apps in a farm, typically) can share information in the database. I guess I couldn't quite believe that the poster would be asking about how the systems can communicate without saying more about it, so I assumed the real problem was a more general "how can we make such a thing as a license system?" and rolled out from there. Peace & Love... :D
dojohansen wrote:
I apologize for retorting!
Also accepted :)
dojohansen wrote:
So you're absolutely right, if maybe needlessly sarcastic,
The sarcasm was unintentional, but on re-reading my post I see why you interpreted it as such. I should make myself clearer!
dojohansen wrote:
I guess I couldn't quite believe that the poster would be asking about how the systems can communicate without saying more about it
I could - I've probably read more posts than you ;) Anyway, on a serious note, I think it would make a good article if you have the time to go into it in a bit more depth as you obviously have some significant experience in this area.
Bob Ashfield Consultants Ltd Proud to be a 2009 Code Project MVP