The main problem about my response is that it was brief, rather than incorrect. For details, look at Real configuration, and specifically http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html
You can then configure tomcat to use a database and keep track of your users. You can then use a lot of things that are built into the server including session timeouts, etc. On Thu, Nov 28, 2002 at 10:57:38PM +0100, Christian Bollmeyer (GMX) wrote: > 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. No true. The way "BASIC" authentication works, you set things up so that the user can't log in twice. > > 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. Probably the easiest way of enforcing this is via cookies, not database flags. > > 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 That's ok. After all it's good to have several opinions on the list. > 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. Don't do it. Why reinvent the wheel. While setting up realms is not trivial, implementing it yourself is going to be at least as much work, and probably not as secure. > > 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. > While this might be true, most modern day web applications are almost useless if they can't trust their database to be up. On top of that, most modern databases are at least as reliable as the servlet engine (after all dbs have been around for a lot longer), so your database uptime's going to be much higher. Specifically in our case, I find our database, Postgres, to be quite a bit more solid than Tomcat. YMMV. > 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 -- 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
