Well... if I most humbly might make some objections...
1. IsUserInRole() is about authorization, so that won't solve the problem at all, I fear. With this method, you can check what a user is allowed to do. You can't check if the user tries to log in twice, regardless of the authentication scheme used. 2. The database approach may work to some degree, but it has some major drawbacks. First, you multiply the critical points of failure. If *either* (|) the web tier or the resource (database) tiers fail for some reason, the user gets locked out. Why? Because the database flag is still set to 'active' or some boolean representation of that state. The same will happen if the session just times out, i.e. if the user doesn't log out as he should (thus, calling something in your code that finally resets the flag after calling session.invalidate()), but just closes the browser. Never assume that something like that will not happen. Most people just close their browsers. I do so, too. 3. You can set the session timeout in web.xml. There is no need for an additional .properties file. 4. No criticism without an alternative suggestion. Mine is loosely as follows: As I understand, no user should be able to log in twice to the same application. So you need application-wide control over things. Luckily, there's something like an application context, and you can store objects in it. Hm. So what hinders you from putting something like a LoginRegistry there? You can use a Vector or an ArrayList, for example, storing the login name there if authentication was successful and the session is created. The difference between Vector and ArrayList is that access to the former's elements is thread-safe while the latter's is not. In this case, as changes are only made at a single point (storing the username; if it already exists, just exit and call session.invalidate() if your code had already created a new session at this stage) and all subsequent operations are read-only, an ArrayList might suffice, and it's faster than a Vector due the aforementioned reasons. During the authentication process, check if there already is a username entry in the Registry. If so, exit and call session invalidate() as explained before. If not, add the username to the LoginRegistry and proceed. In case the user logs out, you just remove the username entry from the LoginRegistry. Advantages over the database solution: if the web tier fails for some reason, the login state is auto- matically reset, as the LoginRegistry is gone for good as well in this case. If the database crashes, that doesn't affect logins anyway (unless your application depends on that elsewhere), for you don't need it to to achieve the result. Still, there's one single critical point left: you have to make sure that the LoginRegistry is kept up-to-date if the container decides to remove a session because a timeout happened. Two approaches are possible: you can either check periodically or get informed. If your Java server implements the current specification (Servlet 2.3/JSP 1.2), you can easily intercept this event via an HttpSessionListener instance. HTH, -- Chris (SCPJ2) > -----Original Message----- > From: A mailing list about Java Server Pages specification > and reference [mailto:[EMAIL PROTECTED]] On Behalf Of > Dror Matalon > Sent: Thursday, November 28, 2002 8:36 PM > To: [EMAIL PROTECTED] > Subject: Re: How should i proceed with > > > At this point you would be replicating a lot of the functionality of > roles in the servlet. Might as well use the built in stuff. Check > out request.isUserInRole(); > > Dror > > > On Thu, Nov 28, 2002 at 11:12:22AM -0000, Peter Dolukhanov wrote: > > A small concern with this is if the user's network > connection dies, or > > the user closes his browser without properly logging off. > To circumvent > > this you should have a method which is called whenever the session > > time's out (expires) and performs the same function to > reset that value > > in the DB. > > > > Regards, > > Peter > > > > -----Original Message----- > > From: A mailing list about Java Server Pages specification > and reference > > [mailto:[EMAIL PROTECTED]] On Behalf Of > Kesavanarayanan, Ramesh > > (Cognizant) > > Sent: 28 November 2002 06:18 > > To: [EMAIL PROTECTED] > > Subject: Re: How should i proceed with > > > > you can have a boolean value at the DB which will be > default to zero. > > once > > he is logged in make that to 1. > > when he logs out make that to zero again. in this way if he logs in > > again > > you can check the value in the DB and prevent him. > > > > HTH > > > > Regards > > > > Ramesh Kesavanarayanan > > [EMAIL PROTECTED] > > > > > > > > -----Original Message----- > > From: V.T.R.Ravi Kumar [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, November 28, 2002 10:17 AM > > To: [EMAIL PROTECTED] > > Subject: How should i proceed with > > > > > > Hi , > > > > I have a situtation where in i have to restrict the access > of an user in > > such way that the user has just one session . that is if he > is logged at > > present then don't let him log again from any other pc > until he logs of > > from > > the previous window .. > > > > How should i proceed with to achieve this.... > > ---------------------------------------------------- > > V.T.R.Ravi Kumar > > Engineer,CCX,BHEL, Haridwar > > Phone : Office-91-0133-485260 > > Res -91-0133-426121 > > ----------------------------------------------------- > > > > > ============================================================== > ========== > > ==To > > unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > > JSP-INTEREST". > > For digest: mailto [EMAIL PROTECTED] with body: "set > JSP-INTEREST > > DIGEST". > > Some relevant FAQs on JSP/Servlets can be found at: > > > > http://archives.java.sun.com/jsp-interest.html > > http://java.sun.com/products/jsp/faq.html > > http://www.esperanto.org.nz/jsp/jspfaq.jsp > > http://www.jguru.com/faq/index.jsp > > http://www.jspinsider.com > > > > > ============================================================== > ============= > > To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". > > For digest: mailto [EMAIL PROTECTED] with body: "set > JSP-INTEREST DIGEST". > > Some relevant FAQs on JSP/Servlets can be found at: > > > > http://archives.java.sun.com/jsp-interest.html > > http://java.sun.com/products/jsp/faq.html > > http://www.esperanto.org.nz/jsp/jspfaq.jsp > > http://www.jguru.com/faq/index.jsp > > http://www.jspinsider.com > > -- > Dror Matalon > Zapatec Inc > 1700 MLK Way > Berkeley, CA 94709 > http://www.zapatec.com > > ============================================================== > ============= > To unsubscribe: mailto [EMAIL PROTECTED] with body: > "signoff JSP-INTEREST". > For digest: mailto [EMAIL PROTECTED] with body: "set > JSP-INTEREST DIGEST". > Some relevant FAQs on JSP/Servlets can be found at: > http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
