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]>

Reply via email to