Hi Jan,
The final ballot of Servlet 3.1 spec has finished.
We will definitely fix the typo 13.8.4.1 in the future.
Per discussion with Ron, we will try to improve examples.
Thanks for your comments.
Shing Wai Chan
On 5/2/13 4:58 PM, Jan Bartel wrote:
> Ron,
>
> Thanks for the speedy reply. Comments inline.
>
>
> On 2 May 2013 23:59, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto:ron.monzillo_at_oracle.com>> wrote:
>
> On 5/2/13 10:47 PM, Jan Bartel wrote:
>> The wording of section 13.4.1 on @ServletSecurity has been
>> updated in a number of places regarding @HttpConstraint with all
>> default values.
>>
>> For example, pg. 127:
>
> The @HttpConstraint annotation is used within the @ServletSecurity
> annotation to represent the security constraint to be applied to
> all HTTP protocol methods for which a corresponding
> @HttpMethodConstraint does NOT occur within the @ServletSecurity
> annotation.
>
>
> Agreed.
>
>>
>> "For the special case where an @HttpConstraint that returns all
>> default values1
>> occurs in combination with at least one @HttpMethodConstraint
>> that returns
>> other than all default values, the @HttpConstraint represents
>> that no security
>> constraint is to be applied to any of the HTTP protocol methods
>> to which a security
>> constraint would otherwise apply. This exception is made to
>> ensure that such
>> potentially non-specific uses of @HttpConstraint do not yield
>> constraints that will
>> explicitly establish unprotected access for such methods; given
>> that they would not
>> otherwise be covered by a constraint."
>>
>> I find this language very difficult to understand and there are
>> no explicit examples of mappings to <security-constraint> that
>> would help de-mystify it.
>> Given this annotation:
>> @ServletSecurity (httpMethodConstraints =
>> @HttpMethodConstraint(value="GET", rolesAllowed = "R1"
>> ))
>>
>> Does the wording of this section imply that the above annotation
>> maps to a single constraint only (leaving out the
>> <web-resource-collection> for brevity):
>>
> yes
>
>
> OK. Can we please have an example added to the spec then to set that
> in stone.
>
>> <security-constraint>
>> <http-method>GET</http-method>
>> <auth-constraint>
>> <role-name>R1</role-name>
>> </auth-constraint>
>> </security-constraint>
>>
>> ?
>>
>> If so, what is the semantic difference to following the rules for
>> mapping to <security-constraints> outlined on pg 131/132, which
>> would result in 2 mappings:
>>
> The pages you refer to and those in
> http://java.net/projects/servlet-spec/downloads/directory/Final
> seem to be different, but I assume you are referring to section
> 13.4.1.2 Mapping @ServletSecurity to security-constraint, which
> also descibes and relies on
> the exception you referred to above. see the text just before code
> example 13-9
>
> "When one or more @HttpMethodConstraint elements are specified,
> the method- independent constraint corresponds to a single
> security-constraint containing a web-resource-collection that
> contains on(e) http-method-omission for each of the HTTP methods
> named in the @HttpMethodConstraint elements. The
> security-constraint containing http-method-omission elements must
> NOT be created if the method-independent constraint returns all
> default values and at least one @HttpMethodConstraint does not.
> Each @HttpMethodConstraint corresponds to another
> security-constraint containing a web-resource- collection
> containing an http-method element naming the corresponding HTTP
> method."
>
> the above says that the first of the following 2 security
> constraints MUST NOT be created.
>> <security-constraint>
>> <http-method-omission>GET</http-method-omission>
>> <user-data-constraint>
>> <transport-guarantee>NONE</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>>
>> <security-constraint>
>> <http-method>GET</http-method>
>> <auth-constraint>
>> <role-name>R1</role-name>
>> </auth-constraint>
>> </security-constraint>
> the purpose of the exception is to retain the ability to
> distinguish (following the mapping) those
> HTTP methods that were uncovered according to case 3 of section
> 13.8.4 Uncovered HTTP Protocol Methods.
>
>
> Ah, so the 2-statement version and the 1-statement version are indeed
> *semantically* equivalent from the perspective of the container's
> application of security to inbound requests. The wording of this
> exception is written from the perspective of enabling the container to
> log a warning about uncovered http methods. The 2-statement version
> produces a constraint which relaxes access for all methods other than
> GET, so no log warning would be produced according to the rules in
> section 13.8.4.2.
>
> Looking again at the wording of section 13.4.1 pg 129 (sorry about
> page number confusion on my previous email), I can see now that this
> is the sense of it, but it was by no means clear, obvious and upfront.
> Can we have a clearer re-wording of this?
>
> Also, there is a typo in section 13.8.4.1 point #3 pg 149:
>
> "If you can’t follow rule #2, declare constraints to cover all HTTP
> methods at each
> constrained URL pattern. Use the <http-method-omission> element or the
> HttpMethodConstraint annotation to represent the set of all HTTP methods
> other than those named by <http-method> or HttpMethodConstraint. When
> using annotations, use the HttpConstraint annotation to define the
> security
> semantic to be applied to all other HTTP methods and configure
> EmptyRoleSemantic=DENY to cause all other HTTP methods to be denied."
>
> The first reference to HttpMethodConstraint should surely be
> HttpConstraint instead??
>
>
>> Also, I cannot see from the spec how I would create an
>> @ServletSecurity annotation that permitted access to an
>> authenticated user that was in any one of the roles defined for
>> the webapp (ie the equivalent of the special
>> <role-name>*</role-name>). The spec and javadoc explicitly
>> states that when used in @HttpConstraint rolesAllowed or
>> @HttpMethodConstraint rolesAllowed, the value "*" has no "special
>> meaning" eg pg 133 and javadocs for both annotations.
>>
> The use of * as a shorthand for all roles declared for the
> application has never been supported
> within @ServletSecurity.
>
>
> Ok, but I fail to see why not. As it was so explicitly excluded, I
> assume there must have been a good reason for it.
>
>
> If that is truly an important semantic for your app, you would
> need to explicitly list all the roles
> that are to be permitted access, or you could define your
> constraint in web.xml; where
> the role-name * has meaning.
>
>
> I'm looking at this from the perspective of container implementer, as
> I am one of the project leads for Jetty. I couldn't find any
> conversation in the archives of the servlet spec 3.0 discussions to
> support why such an exclusion would have been made. Jetty has not
> implemented this restriction to date, thus I wanted to understand its
> purpose so that we could address it if need be in our spec 3.1
> implementation.
>
>
> With the addition of support for the ** role, applications may be
> less inclined to need to
> indicate that access is to be permitted to all roles declared for
> the application.
>
>
> Well, they serve different purposes.
>
>
> Jan
>
>
> Ron
>> ?
>>
>> Jan
>>
>>
>> --
>> Jan Bartel <janb_at_intalio.com <mailto:janb_at_intalio.com>>
>> www.webtide.com <http://www.webtide.com> – Developer advice,
>> services and support
>> from the Jetty & CometD experts.
>
>
>
>
> --
> Jan Bartel <janb_at_intalio.com <mailto:janb_at_intalio.com>>
> www.webtide.com <http://www.webtide.com> – Developer advice, services
> and support
> from the Jetty & CometD experts.