well yes, this is actually the way I do it now - lets call this self implementet security. I was just looking into using javas security features, like the principal object and so on. Using a std. implementation insted of my own. Right now, if someone logges in, I lookup a user object in the database and if pressent I put it in the session. Then when a user tryes to access some page or a page needs to know if it should render one part of the page or another it look for this user object in the session. If pressent then its ok, if not, redirect to a dedicated loginpage/errorpage.
But as stated. I would like to use a std. implementation and javas build in security features. But it looks like http://securityfilter.sourceforge.net/ has something to offer... havent had a change to look closer at this implementation yet ... Jan ----- Original Message ----- From: "Jose Alfonso Martinez" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Saturday, November 02, 2002 4:38 AM Subject: Re: Form auth > Jan, I guess I cannot understand your problem. The way I do it on my site is very simple: > > A loginform on the front page. > When the user logs in, get the user permissions from the database and store them in the session. > Then, JSPs are rendered accordingly depending on those permissions. > > I guess most sites use this approach. I think you could do it the same way too. Couldn't you?? Simply: > > if the user has some permissions -> render the page some way > if the user does not have permissions -> render it some other way > if the user has not logged in at all -> render it some other way... > > Jose Alfonso > > On Nov 01, 2002 at 10:18:17AM +0100, Jan Agermose wrote: > > Im used to work in a different way - not using declarative security. Might > > be the real problem :-) It seams, that this decleartive security thing is > > good for resources that are allways protected or not. My pages are mostly > > partly secured in that all users can access some page but some items on the > > page are displayed only if the user is logged in. Or a page that is > > displayed in a context. In one context it is OK to see the page and > > depending on some parameter (the context) it might not be ok. Runtime > > checked security. I really need to have the user login at will not foreced - > > but allso foreced of cause. This idea of a button and a fake-secured-page > > that forces a login prompt. I really want a loginform on the frontpage. I > > dont want the user to have to klik a button only to get to the loginscreen > > af submit that one. I cannot change a design just because of a "design flaw" > > in the backend code ;-) I really should be possible to submit login > > information on free will. > > > > Allso what You described below seams to be exacly what is allready > > implementet in formauth method? > > > > Jan > > > > > > ----- Original Message ----- > > From: "Alfonso Martinez" <[EMAIL PROTECTED]> > > To: "Tomcat Users List" <[EMAIL PROTECTED]> > > Sent: Friday, November 01, 2002 6:00 AM > > Subject: Re: Form auth > > > > > > > One way to do this is to create a filter for the protected resources. When > > accessing them, the filter gets invoked. It checks on the session wheter the > > user has already logged in or not. If not, it redirects to the login page > > which in turn redirects to the protected resouce. What do you guys think > > about this approach??? > > > > > > Jose Alfonso > > > > > > On Thu, Oct 31, 2002 at 10:19:16AM -0800, Craig R. McClanahan wrote: > > > > > > > > > > > > On Thu, 31 Oct 2002, Jan Agermose wrote: > > > > > > > > > Date: Thu, 31 Oct 2002 17:15:08 +0100 > > > > > From: Jan Agermose <[EMAIL PROTECTED]> > > > > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > > > > To: 'Tomcat Users tomcat <[EMAIL PROTECTED]> > > > > > Subject: Form auth > > > > > > > > > > I would like to use formbased auth for my application, but it seams, > > that it is based on > > > > > 1. user trying to access som resource > > > > > 2. if not logged in - prompt > > > > > > > > That's correct. From the user point of view, it operates exactly like > > > > BASIC authentication does (where the browser pops up the login dialog > > the > > > > first time you ask for a protected resource). > > > > > > > > > > > > > > This is of cause good. But usualy you have a webpage that has a > > > > > login-form somewhere on the page to allow the user to log in at will. > > > > > Log in -before- a secured page is requested. How can I implement this? > > I > > > > > find only methods to getRemoteUser and isInRole and... no > > setRemoteUser > > > > > or the like... > > > > > > > > > > > > > You won't be able to have the login form itself on the unsecured page, > > but > > > > you can easily provide a "Log In" button (say, on your home page) like > > > > this: > > > > > > > > * Make the log in button link to a resource in a protected directory > > > > > > > > * Make that resource just do a redirect back to the home page > > > > > > > > When the user clicks the log in button, the form based login page gets > > > > displayed (because the resource is protected). After login is complete, > > > > Tomcat then executes the protected resource, which redirects back to the > > > > home page with the user being logged on already. > > > > > > > > > Am I making sense :-) > > > > > > > > > > Jan > > > > > > > > Craig > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > > > > For additional commands, e-mail: > > <mailto:tomcat-user-help@;jakarta.apache.org> > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > > > For additional commands, e-mail: > > <mailto:tomcat-user-help@;jakarta.apache.org> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > > For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> > > > > -- > To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
