Re: a 'one-click' j_securty_check question

[David Cassidy <da...@twocats.co.uk>]

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:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: a 'one-click' j_securty_check question

[jfc <jf...@btopenworld.com>]

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:   
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail: 
>> <ma...@jakarta.apache.org>
>>
>
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>
Thanks for that I'll have a read.

jfc



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>