how to restrict users

[Srinath R]

Hi All,
How to restrict the customer for having more than five users accessing the application.The application has got its own database which keeps track of all the user info.
Although i use a counter to do this job, how can i be sure that the customer does not alter the Database or for that matter even the counter.

[Ashwin Desai]

Hi,
Use a counter that gets incremented when a customer accesses the application. When the customer closes the application, decrement the counter.
The above assumes that the customer accesses a single instance of the application.

public class Counter
{
private int current;
private static int counter;
public Counter(){
current = 0;
counter = 0;
}
public int inc(){
current = ++counter;
return current;
}
public int dec(){
current = --counter;
return current;
}
}

public class Application
{
Counter counter = new Counter();
public void start(){
// Start the application. The entry point.
if (counter.inc() > 5){
// return error.
}
else
{
// proceed.
}
}
public void stop(){
// When customer logs off.
counter.dec();
// cleanup.
}
}

Hope this helps.
Ashwin.

[parind poi]

If you do not want to hard code the value in the app, You can encrypt the value before writing to the database and then decrypt it when you start the app. JCE is a easy way to do that.
Parind

[Desai Sandeep]

The alternative for hardcoding is to use a properties file and read that file.You may change the values in the text file if you desire.However, this will not result in the compilation of the code.
-- Sandeep

[Srinath R]

hi Ashwin Desai,
by saying "no. of i users", i did not mean "no. of users at a given time" but instard i ment "no. of users that are present in the data base"
if u could help me with that it would be great.

[Srinath R]

hi Desai Sandeep
if u could give some sample code that would manage this property file it would be great, is this property file some think like the .ini file that is used by VC++ to handel data?
expecting responce!

[Desai Sandeep]

Hi Srinath,
Assuming that you have a property file called "srinath.txt".In this file, you may have a Name=Value pair say:
<pre>
noOfUsers=10
</pre>
In your code, you may say :
<pre>
Properties props = new Properties();
prop.load("srinath.txt");
String noOfUsers = prop.getProperty("noOfUsers");
</pre>
However, you would still need to write a code to know how many users are accessing your database.If you have that information stored in the table, I would suggest you create "srinath.txt" file by using IO after getting the value from the table using JDBC.
Hope this helps,
Sandeep
[This message has been edited by Desai Sandeep (edited July 12, 2001).]

[Fred Abbot]

you can add a table to your database that stores the users logged in if they try to log in again throw an error message
sayin you are all ready logged in

[Desai Sandeep]

Originally posted by Fred Abbot:
you can add a table to your database that stores the users logged in if they try to log in again throw an error message
sayin you are all ready logged in

The other way would be to use the implicit objects of JSP like the session,application,etc.You could put the logged in user in the implicit object, perform a check everytime the user is logging in; if logged in already display an appropriate message.
Hope this helps,
Sandeep
[This message has been edited by Desai Sandeep (edited July 13, 2001).]

[Srinath R]

hi all
Hi Fred Abbot & Desai Sandeep
once again i would like to make it very clear by saying "number of users" i did not mean "number of users at a given instance of time" but i ment the total number of users that can be allowed to have access to the program
Or in other words some thing like say, i need to give some user licence for a fixed number of users then how do i do this. and how do i make sure that my customer does not violate the licence.

[Jim Yingst]

Well, whatever solution you end up using, be sure to use some sort of obfuscator to make it more difficult for the user to reverse engineer.
OK, storing user names in the database probably isn't good enough. You can limit concurrent users this way perhaps, but whoever owns the database has the power to edit this table, which would mean they can swap users in & out at their convenience.
How about this - maintain an encrypted file which lists all registered users. Users can register only using your program, which will limit the number of registered users allowed. Since it's encrypted, the users should have a hard time editing this file. They could swap it for an old copy perhaps, which may be useful in some cases. (Esp if you allow users to unregister, which might undermine this whole system.) You can make this more difficult by also storing the time of last access in this file, as well as other places on the system (like in the DB). If your program finds evidence of other accesses more recent than what the file indicates, it can disable itself somehow. (Of course, you'll want to test this very carefully before releasing it to the coderanch.)
Hmmm... if you allow unregistration or license transfer, what would prevent users from swapping the license regularly - so that again, you're only limiting concurrent users, not total users? Offhand, the encrypted user file could also include records of former users. You could put in limits then - e.g. "once a given user is unregistered, they can never reregister" or "no more than one reregistration per user". Or the overall license could be for X total users, with Y allowable unregistrations (so the total number of users in the product lifetime would be X + Y, since each unregistration allows one more registration of a different user. You can even make it so that exceeding limit Y simply forces the users to contact your company to get a new license file. This allows you to review their situation and see if there's a justification for all the reassignments. Did they go through a reorganization of some sort, with lots of new hires? Or are they just swapping licenses between the same users?

[Srinath R]

hi Jim Yingst
what u said defenately looks good but i am not aware of the way that i have to go about in using this encripted file if u can ive some sample code it would be helpful.
expecting the same
srinath

[Desai Sandeep]

Srinath,
I thought my solution of having an external file with the name=value pairs is very similar to what Jim has suggested.
Jim, correct me if I am wrong!
Yes, the encryption feature needs to be taken care of.One of the ways of doing it is to use make the file unreadable by using Serialization.However, this is not a very good encryption technique but still worth starting with.May be you need to refer to some better encrpytion algorithms for it.
So, in the text file We may some pairs like:
<pre>
AllowableUsers=200
NoOfRegisteredUsers=100
</pre>
You need to think of variables that are required for your application.I believe this solution would work irrespective of whether you want to keep track of how many users have logged in or how many licenses needs to be distributed.Once you have name=value pairs in place it is just a question of manipulating them using the Java API's.Ofcourse, as I said encryption is a seperate issue.
Does this help?
Sandeep
[This message has been edited by Desai Sandeep (edited July 15, 2001).]

[Jim Yingst]

Yes, the properties file idea is simial - it's a matter of deciding what info to store. I'm inclined to think you should have a way of storing the user names too - otherwise, where to put them? The database seems the obvious choice, but what would prevent a DBA with the appropriate passwords from altering this list whenever a new user wants to log in? I don't really know that much about database security; maybe there's a way to do this - but I'm thinking that, unless the database is completely encapsulated within your product and under your program's control (no need for anyone else to have passwords) then at least one other person will have access to it, which is undesireable.
As for "encrypting" with serialization, this is hardly worthy of the term "encryption". Create a serialized object file of something, and then open it with a simple ASCII text editor. You will most likely see all the Strings in the object in plain text. Other data structures are a little less obvious, but not much. I haven't done any real cryptography with Java, but here are some likely resources:
The Java Cryptography Extension (JCE) from Sun
Java Cryptography, by Jonathan Knudsen (O'Reilly)

[Roy Tock]

Hey, Srinath, take this tip from an old hand...
If you're going to keep the user count or information in a data store, be dern sure that access to that store is synchronized. Not just across a single application, either, but across all applications that hit the store.
A database is a decent solution; the DBMS will help you handle synchronization. *You* will have to handle some form of database security, though, so your users don't hack your data. Data obfuscation is not generally real security; it can be effective for an unsophisticated audience. If this is a production system, you can safely assume that users WILL hack your data if they have any motivation whatsoever to do so, and that even an unsophisticated audience will stumble their way into an unprotected data source.
In any case, if this is a production system, your users could get around your restriction by logging in multiple times as the same user somehow, unless you put a restriction on the number of times a single user can login concurrently. That will also require some tricky work, probably with a database and obfuscated data, unless your environment handles it for you somehow.
Good luck!