----- Original Message ----- From: "Dror Matalon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 29, 2002 7:16 AM Subject: Re: How should i proceed with
Hi, -- CLIP > > 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. Now this is interesting. How would one 'set things up' so that a user can't log in twice using declarative security? I may be dumb, but I just didn't find any fitting mechanism for that. Considering realms: I always had the impression that realms were basically a (container-specific) means of telling Tomcat where to look for the credentials and map usernames to roles. I can't see why using BASIC authentication makes any difference in this context. In fact, even re-reading the Tomcat realms how-to didn't help. I just can't see what roles may have to to with the number of logins a user may perform concurrently. But obviously I'm wrong or missing something. Would you care to explain the details? -- CLIP > 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. We even use the 'unbreakable' one, but that's not the point. If you store session state information in a database - which may be a necessity in distributed applications -, you'll also have to have a means to keep the database in sync with the web tier. Otherwise, if the web tier crashes, the 'active' flag will still be there, effectively keeping the user out. @Ravi: http://www.stardeveloper.com/articles/display.html?article=2001111901&page=1 http://www.stardeveloper.com/articles/display.html?article=2001112001&page=1 How to implement a global UserRegistryBean stored in the ServletContext (application scope) is also explained in detail in the O'Reilly JSP book. You can easily adapt the mechanism described there to not storing a token in the session scope after succesful authentication, but maintaining a Collection of loginNames in ServletContext instead, using a listener in place of a filter and the like. If you don't have the book, you might still want to look at the example sources, available from http://www.thejspbook.com/download.jsp. -- Chris (SCPJ2) =========================================================================== 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
