• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Difference between empty auth-constraint and no auth-constraint.

 
Sanjeev Ba
Ranch Hand
Posts: 40
Android Chrome Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ranchers,
I wanted to know the effect of having two sercurity-constraint elements in the DD one with an empty <auth-constraint/> = allowing no one and the other with no auth-constraint element.

Is the result, allow everyone or allow no one? Which one takes precedence.

Also, I observed that there is some issue with the evaluation part of Whizlabs simulator. I does not exactly calculate the number of right answers properly. Has anyone else faced the same issue? I am using the trial version.

Thanks and Regards
Sanjeev
 
Gowher Naik
Ranch Hand
Posts: 643
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried <auth-constraint/> and no auth-constraint and i found it allows everyone.
 
Niranjan Deshpande
Ranch Hand
Posts: 1277
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
empoty <auth-constraint/> - NO one is allowed

no auth-constraint - every one is allowed, its same as
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
 
Sanjeev Ba
Ranch Hand
Posts: 40
Android Chrome Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Gowher for quickly testing it out.

Regards
Sanjeev
 
Sayak Banerjee
Ranch Hand
Posts: 292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I tried <auth-constraint/> and no auth-constraint and i found it allows everyone.

Well, that's not possible.....could you please post the code for the DD?

<auth-constraint/> means no access to no one.


Also,

no auth-constraint - every one is allowed, its same as
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>

<auth-constraint> element missing is not exactly the same as
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>

Though everyone is allowed in both cases, the former one allows unauthenticated access
[ January 02, 2007: Message edited by: Sayak Banerjee ]
 
Gowher Naik
Ranch Hand
Posts: 643
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[code]
<web-app...>
<security-role>
<role-name>admin</role-name>
</security-role>
<security-role>
<role-name>tomcat</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>MySecureWebResource</web-resource-name>
<http-method>GET</http-method>
<http-method>POST</http-method>
<url-pattern>/start.jsp</url-pattern>
</web-resource-collection>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>MySecureWebResource</web-resource-name>
<http-method>GET</http-method>
<http-method>POST</http-method>
<url-pattern>/start.jsp</url-pattern>
</web-resource-collection>
<auth-constraint/>
</security-constraint>

</web-app>
The above code from DD allows both admin and tomcat users.
 
Gowher Naik
Ranch Hand
Posts: 643
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Above code allows both tomcat and admin users.
 
Sayak Banerjee
Ranch Hand
Posts: 292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There you go man.....I was pretty sure that you were combining constraints.....The information that I provided was about a single <security-constraint> element in the DD....

Tomcat 5.0.X does not strictly adhere to the spec. as far as combining <security-constraint> elements are concerned.....I dunno if they've corrected it in version 5.5.X but I had the same problem when using version 5.0.28....You can check this ISSUES WHEN COMBINING CONSTRAINTS
 
Sayak Banerjee
Ranch Hand
Posts: 292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As for the question originally asked by Sanjeeva,
Hello Ranchers,
I wanted to know the effect of having two sercurity-constraint elements in the DD one with an empty <auth-constraint/> = allowing no one and the other with no auth-constraint element.

Is the result, allow everyone or allow no one? Which one takes precedence.


Answer is (according to the spec.) : - No access to no one
 
Joe Harry
Ranch Hand
Posts: 10080
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sayak,

How come <auth-constraint/> and no auth-constraint will give access to no one?? I feel that it will give access to everyone. The no auth-constraint overrides <auth-constraint/>. Can anyone please give me the spec reference here?? Please!
 
Gowher Naik
Ranch Hand
Posts: 643
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

From above specification i think no one will be allowed.
 
Joe Harry
Ranch Hand
Posts: 10080
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Gowher,

Your replies contradicts...

Your pfirst post says "I tried <auth-constraint/> and no auth-constraint and i found it allows everyone."

and

The above one says, from the servlet spec that no one is allowed. So servlet spec is the final and no one will be allowed is the conclusion for the above original question by Sanjeev.

Thanks ranchers.
 
Gowher Naik
Ranch Hand
Posts: 643
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This problem has occured before also
Check this PostSecurity
So i will go with specification.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic