Thanks Craig. Don't mean to take this too far off topic, and am not trying to start a flame with it. I am curious as to why this is a non-portable feature. Or is that what you mean. That it is an implementation artifact of Tomcat and not in the servlet spec? I think there are a lot of options, this was just one. Certainly you could auth at the webapp and use the username to do a look up somewhere else for database creds. But forms auth can also be useful (assuming https). I "rolled my own" becuase the container didn't provide what I needed, and that is the way it should be. But the whole idea here is to keep the security at the database, so people in the organization can't mess around with it.
-----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 2:28 PM To: Tomcat Users List Subject: RE: j_username in session cookie - where did it go? On Wed, 14 Aug 2002, Mark Schmeets wrote: > Date: Wed, 14 Aug 2002 13:47:48 -0400 > From: Mark Schmeets <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: RE: j_username in session cookie - where did it go? > > Well, I know there are a lot of other ways of doing this, but having the > username and password from forms auth makes it very simple. The username and > password are for the database. The servlet app isn't necessarily the only > app to access certain data, there may well be some legacy and client-server > apps too. Besides, some architects like to keep security at the database > level. > I didn't mean to suggest that there aren't other ways, just that Craig's > suggestion sounded pretty severe. > Sorry ... but that's the kind of thing that happens when you depend on non-portable features of one particular version of one servlet container. Of course, the idea of using the same username/password for access to the webapp (where any network snooper can read them) *and* the database (where anyone inside your organization can cause all sorts of mischief) doesn't sound like a real secure design in the first place, but that's a whole different discussion. Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
