Hi,
On 29/10/13 12:58, Winnebeck, Jason wrote:
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Tuesday, October 29, 2013 8:09 AM
SecureAnnotationsInterceptor is at the PRE_INVOKE stage, so I wonder
how the call reaches it when WADL is requested, given that
JAXRSInInterceptor which runs a WADL filter is at the earlier UNMARSHAL
stage.
I just debugged this. CXF 2.7.7 calls AbstractAuthorizingInInterceptor, which calls
getTargetMethod. It finds that m.getExchange().get(BindingOperationInfo.class) and
m.get("org.apache.cxf.resource.method") return null. Because it cannot perform
its work it decides to be safe and throw access denied.
In debugger I see that JAXRSInInterceptor's handleMessage is called first. It
finds a RequestProcessor, and calls its preprocess method, which puts a
Response onto the Message's exchange which has entity with WADL content, which
bypasses the rest of JAX-RS logic. Then SecureAnnotationsInterceptor runs and
throws from its handleMessage, and it seems that this overrides the Response
generated by JAXRSInInterceptor.
I created a class that extends SecureAnnotationsInterceptor, whose
handleMessage is below:
void handleMessage(Message message) throws Fault {
if (!"_wadl".equals(message.get(Message.QUERY_STRING))
super.handleMessage(message)
}
And now my service "works", but any user calling for example /api/soap?_wadl can perform
any SOAP operation. I could check for "org.apache.cxf.rest.message" property, but I'd
rather find a better approach than risk making a security flaw.
I should also note that my goal here is only to get CXF + spring-security to work at all.
SecureAnnotationsInterceptor was my backup plan. I initially tried
<sec:global-method-security jsr250-annotations="enabled"/> in the beans XML,
but this causes an InternalServerErrorException thrown from at
org.apache.cxf.jaxrs.utils.InjectionUtils.reportServerError(InjectionUtils.java:457) in
cxf-rt-frontend-jaxrs-2.7.7 jar, the real cause is line 302 (injectThroughMethod), where it
catches an exception because Spring Security creates a proxy, and CXF has a reference to the
Method from the real class, and calling realMethod.invoke(proxy, ...) fails because the proxy's
class does not extend realMethod's class. This might be due to a @Context method setUriInfo on
the implementation class rather than the interface. This method would probably be better if
possible, because I'd like to use an exception mapper, which doesn't appear possible via the
interceptor method.
Right, it is a fault that the in chain is not aborted immediately when
Response becomes available as it interferes with the CXF interceptors
which 'think' the invocation is still ahead. Will have to investigate.
Please use
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.7/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/security/SimpleAuthorizingFilter.java
on the JAX-RS path instead, it should resolve this issue
Cheers, Sergey
Jason
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message and any attachments.
