Hi.
I just dug out an old yet related thread that came up on this a few
years back.
Here is some of the info that came out of an exchange which dates back a
few years.
(Question) I believe the @ServletSecurity annotation is the
preferred way to handle programmatic security constraints and can be
used in combination with a new DD element that will allow setting
default behavior to DenyAll. Along with this, the plan going
forward is to move away from using DenyAll, PermitAll, and
RolesAllowed. (per Servlet 3.1 EG draft spec section A.2) Does
this sound correct?
(Answer) yes. and to be clear. Servlet did not require or even
describe the use of any of the above;
(Question) I am looking at the Servlet 3.1 spec (EG draft) and am
curious if the plan is to deprecate the following:
@RolesAllowed
@PermitAll
@DenyAll
(if so, should the spec say these are deprecated ?)
(Answer) the servlet spec should not include any reference to those
annotations. they are defined in jsr 250, and required to be
supported in specific contexts, but so far that has not included
Servlet, as they were found to be a bad match for Servlet's
url-pattern based constraint methodology.
(Question) In an earlier version of Servlet 3.0 spec, there was a
section on (13.4.1) "Mapping Access Control Annotations to
Constraints". This gave a nice example of usage.
Will there be anything similar that shows the preferred way to do
something instead of using annotations of @PermitAll, @DenyAll,
@RolesAllowed?
(Answer) afaik, those annotations i wll not be supported by servlet
Bottom line: It was my understanding that the @RolesAllowed,
@PermitAll, and @DenyAll should not have appeared in the final release
of the servlet spec. And that the preference was to use
@ServletSecurity instead of @RolesAllowed.
Sorry but that's all I really have on this.
thanks,
paul
On 10/27/16, 10:22 AM, Michael Remijan wrote:
> I'm trying to figure out the relationship between @RolesAllowed and
> @ServletSecurity in servlets.I'm using an EE7 server which means
> Servlet 3.1.Long story short, it seems like @ServletSecurity works but
> @RolesAllowed does not.
> In section "A.3 Changes since Servlet 3.0 Public Review", the servlet
> specification says:
>
> "Added support for security related common annotations -
> @RolesAllowed,_at_PermitAll, @DenyAll"
> This leads me to believe that @RolesAllowed should work in3.1.
> However, In section "A.2 Changes since Servlet 3.0 Proposed Final
> Draft" the servlet specification says:
> "Added a new annotation - @ServletSecurity (and associated annotation
> for the
> fields) for defining security as opposed to re-using the @RolesAllowed,
> @PermitAll, @DenyAll"
> So am I correct in assuming that the @RolesAllowed annotation was
> originally supported but is no longer supported in favor of
> @ServletSecurity?
>
>
> On Thursday, October 27, 2016 8:33 AM, "violetagg_at_abv.bg"
> <violetagg_at_abv.bg> wrote:
>
>
> Hi,
>
> I would like to ask for a clarification about
> ServletOutputStream.setWriteListener.
> In the specification it is not clear when it is allowed to invoke this
> method.
> Should the application go to a non blocking mode right after
> AsyncContect.startAsync while in the container thread or that call can
> be delayed and made from a different thread.
> In Tomcat we allowed a delayed call to this method however we have
> edged use cases [1] and [2] when this causes problems.
> The same question applies also for ServletInputStream.setReadListener.
>
> Thanks in advance,
> Violeta Georgieva
>
> [1] http://marc.info/?t=147756348200005&r=1&w=2
> <http://marc.info/?t=147756348200005&r=1&w=2>
> [2] http://marc.info/?t=147696900800002&r=1&w=2
> <http://marc.info/?t=147696900800002&r=1&w=2>
>
>