Eddie Bush wrote: > Suggestion: Search the archive. This is a very frequently asked > question. > > What you want to do is the same as everyone else using FORM-based CMA. > The fact is that it doesn't work on a "let" basis; rather a "make" > basis. One hint I will give you: the container is going to load all > of a user's roles when they login. They don't login as a given role > (to my understanding anyhow), but simply login -- all associated roles > are loaded on successful authentication. > > Regards, > > Eddie > > 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 Eddie!
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>