+1. We need the language. We also need a ForbiddenException.
On 10/28/2012 8:56 AM, Markus KARG wrote:
> Experts,
>
> I'd like to ask you to comment this feature proposal
> http://java.net/jira/browse/JAX_RS_SPEC-304 for improved integration of
> JAX-RS with EJB security annotations. :-)
>
> Regards
>
> Markus
>
> *From:*Marek Potociar [mailto:marek.potociar_at_oracle.com]
> *Sent:* Samstag, 27. Oktober 2012 18:10
> *To:* jsr339-experts_at_jax-rs-spec.java.net
> *Subject:* [jsr339-experts] Re: Integration of Java EE security
> annotations with JAX-RS 2.0
>
> I don't think that's something we would be able to specify in JAX-RS 2.0
> timeframe.
>
> Marek
>
> On Oct 27, 2012, at 4:01 PM, Markus KARG <markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu>> wrote:
>
>
>
> Experts,
>
> possibly I (again) missed an already finished discussion (I am happy if
> you send an archive URL in that case)…:
>
> I want to ask whether there are plans to integrate JAX-RS 2.0's
> automatic creation of "Allow:" (as a rection to OPTIONS) with Java EE's
> security annotations like "@RolesAllowed"?
>
> Example:
>
> Given the following EJB-integrated JAX-RS resource…
>
> @Path("/stats") @Stateless class UserStatistics {
>
> @GET @RolesAllowed("Administrators") public
> getSomeInteresticMetrics() {…}
>
> }
>
> …will the automatic OPTIONS response provided by a compliant JAX-RS
> implementation have to automatically omit "GET" in case the caller is
> not authenticated and authorized as an Administrator?
>
> If not, this would be a really brilliant addition the the
> EJB-integration chapter of the spec, as it allows client applications to
> prevent a GET invocation completely, hence show a "disabled" GUI or
> suppress a senseless network roundtrip. :-)
>
> Regards
>
> Markus
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com