David Cassidy wrote: > i think that unless Im completly missing your point your missing the > Realm's point. (Or I am) > > When you log in using the realm it takes from the database all your > associated roles. ie > if you have admin, editor and journo roles but you only need 'editor' > role for the area you want > to go into TC gets all the roles and associates it with your principle. > > > Have a look at RealmBase > > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/index.html > > > You can then get the principle for that user then check if that user > is in a > given role. You can then build your page based on those roles. ( which is > what I think you are trying to do ) > > Hope this helps > > D > > > jfc wrote: > >> Hi, >> >> I would like to structure my application so that the user can choose >> to login instead of being enexpectedly prompted to be logged in. >> >> It seems declarative form-based security comes with the philosophy >> that your URL has to explicilty request a resource which is secured >> under the role you wish to log in under in order for the container to >> know you belong to that particular role(i.e. >> request.getRemoteUser()). So you have to know before hand who you'd >> like to be logged in as. >> >> I could force the user to choose from a list of valid roles before he >> gets propmted by the j_security_check login form but I'm trying not >> to have force the user to identify himself to the container twice in >> order to be thoroughly recognized by the container. >> >> My question: >> >> Is the following possible under the latest spec and tomcat's >> implementation (using j2ee, declarative form-based authentication >> ): >> >> 1. user issues a request to manually log in with the custom html >> login form containing the users username and password; >> 2. server extracts role-leaf from this user's registration >> information from a persistent store i.e. the application holds roles >> in a hierarchy; >> 3. server does a redirect to a welcome page secured in web.xml >> under that role-leaf role value; >> 4. the configured login page has the j_security_check form >> prepopulated with username and password; >> 5. the configured login page also has an 'onload' javascript >> directive which automatically submits j_security_check on loading of >> the body. >> >> I haven't tried this yet but does anyone have any experience of >> something like this working? >> >> If so it would mean that an application would not have to show links >> whose appropriateness would only become apparent once that link had >> been followed(clicked) and the user had possibly failed at his >> attempted login. >> >> Sorry if this is not clear enough. >> >> jfc >> >> (the container needs to first know what role you want to log in under >> in order for it to successfully authenticate you under that role. It >> can't determine for itself which role you registered under and >> attempt to authenticate you under that role instead) >> >> >> -- >> 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]> > > Thanks for that I'll have a read.
jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
