Fog Creek Software
Discussion Board

How to protect web-based app?

Hi all,

We are creating web-based application using JSP and Struts. We would like to limit the number of concurrent users, and if the limit is reached, new users won't be able to log on.

The trouble is, the application will be deployed on the customer's computer. Is it possible to somehow protect the logic that handles the logon process and user autentification from being potentially modified by the customer?

Thanks in advance for any feedback, positive or negative!

Friday, May 24, 2002

How about using semaphor based locking model using a database table.

Make the number of users configurable in a tunable table, once max number of users have logged on, allow no more.

If it is a web app, why would it be deployed on the users computer? (have not used struts, so maybe that's why I ask)

Brad Clarke
Friday, May 24, 2002

Definitely don't put the login logic in a JSP since pretty much anyone with write access on the machine can make changes.

I have not done this, but signing and sealing the jar should help you make sure your code is running, and not someone elses.

Friday, May 24, 2002


Our customers will install and run the app as their "corporative" server.
It's easy to keep track of users, and to allow/disallow logon, we just don't want anyone to modify the app and disable these nice features.


Thanks for the suggestion to sign/seal the jar file. We also plan to emit the most significant HTML content from custom JSP tags, and as a side effect these tags can test if the logon was real, not faked by altered JSP page.

On the related note, what would be the good way to prevent customer from buying one copy and installing it in multiply places?

Friday, May 24, 2002

To make sure that you have no more than 10 active sessions, create an Application scope JavaBean that keeps track of the number of active sessions.

Create an Event listener for session creation and session completion that increment and decrement the count on as sessions are createdand destroyed.

For the deploy multiple times, make them enter the key on an admin screen when they first start the program.  persist if.  Give them a key tied to the machines MAC adddress.  Yes, they can spoof it, but for a corporate machine, they are not too likely.  Have a filter that checks for the key before any important action, or extend the Struts ACtion Servlet to do this itself.

Friday, May 24, 2002

Why not using a filter instead of mssing with all the apps ?

Saturday, May 25, 2002

Because the filter can be removed or replaced by the customer.

Saturday, May 25, 2002

Not reall an answer to the question you asked but... I'm guessing that you want to prevent more logins because the customers only paid for X and should only be allowed to use X. If it's because the system won't handle more than X that's another issue:) If you distrust your customers so much that you think they'll hack your code that may be a bigger problem. One possibillity is not to disallow logins but to keep track of the maximum number of concurrent users and just ask them to buy more licenses. A lot depends on how many copies you expect to sell etc. If these are big accounts then no license, regular contact with the help desk/consultants, and the knowledge they signed a legal agreement when they purchased the stuff is what's been used elsewhere.

Alex Moffat
Saturday, May 25, 2002

>Why not using a filter instead of mssing with all the apps ?

Solves a different problem.  The other new thing in the 2.3 servlet api is the event listenres, and this is what you need to free up the slots when a session times out.

Tuesday, May 28, 2002

>Is it possible to somehow protect the logic that handles the logon process and user autentification from being potentially modified by the customer?

You should take this logic out of the JSP and put it in a bean or servlet.  The customer can't make changes to a the compiled byte code.

Tuesday, June 4, 2002

With browser clients, how do you define 'concurrent users'?  For example, if I navigate to your site and log in and then promptly go off to, am I counted as a concurrent user?  For how long?  Similarly, what if I log in, start doing stuff and then go have a coffee break while leaving my browser open on some intermediate page in the web app.  If the answer to 'how long' above is less than my absence then I'm a gonna be pissed when you 'lose' my 'concurrent' connection.  If  you build in the ability to seemlessly reconnect me, then what if the reconnection puts me over the concurrent limit?  Problem is, the user experience suggests that they are always connected because their browser is always displaying your app.  So if you tell them the limit was reached, they're not going to understand and if their reconnect rejection results in lost work, then you have a bigger problem.

The whole concurrent user usage model works well for always connected client-server applications, but really poorly for the stateless HTTP environment.

Wednesday, June 5, 2002

*  Recent Topics

*  Fog Creek Home