Given following in DD <security-role> <role-name>Member</role-name> </security-role> Which are valid <auth-constraint> elements that will allow user to access resources constrained by security role declared?
A. B. <auth-constraint>Member</auth-constraint> C. <auth-constraint>*</auth-constraint> D. E.
Here's Errata's correction:
[785] Question 43; options B-E should include the inner <role-name> tags as the read demonstrates here. Example: <auth-constraint> <role-name>Member</role-name> </auth-constraint>
The anwser is B and C. ============================ I think only C is correct.
Because option C means everybody has to access to resources, then what's the meaning of declare security role to Member?
Because option C means everybody has to access to resources, then what's the meaning of declare security role to Member?
The security-role tag only declares some roles used in the web application. In this example, there's a role called Member.
Using this role, you can grant access to some of your protected resources via either : <auth-constraint> <role-name>Member</role-name> </auth-constraint> OR <auth-constraint> <role-name>*</role-name> </auth-constraint>
The second means ANY role, Member being implicitly included.
the <security-role> tag in the DD is a way to declare the container upfront about the security roles which would be used in the application.
If you make a call in a servlet as follows: isUserInRole("admin")
then the container checks the <security-role> to see if "admin" is defined or not. If not then it checks the <security-role-ref> in the servlet tag to see if a custom role has been defined.
then the container checks the <security-role> to see if "admin" is defined or not. If not then it checks the <security-role-ref> in the servlet tag to see if a custom role has been defined.
Actually, it's the opposite.
nitin pai
Ranch Hand
Joined: May 30, 2006
Posts: 185
posted
0
oops.. ya its first <security-role-ref> and then <security-role>