You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Sergey Beryozkin (JIRA)" <ji...@apache.org> on 2014/06/13 22:35:02 UTC

[jira] [Comment Edited] (CXF-5803) Injection of SecurityContext

    [ https://issues.apache.org/jira/browse/CXF-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14031115#comment-14031115 ] 

Sergey Beryozkin edited comment on CXF-5803 at 6/13/14 8:33 PM:
----------------------------------------------------------------

Hi Andrei

We have standard JAX-RS contexts - this must be supported.
CXF also supports the injection of custom context classes but it has to be in turn supported by additional ContextProvider providers but it is not an out of the box support, it is optional depending on the availability of such providers. So if CXF-specifc SecurityContext needs to be injected then ContextProvider provider returning CXF SecurityContext needs to be registered.

I'm not sure we should prevent NPE - if it happens then it is a bug - either on CXF side or on the user side, for example, ContextProvider supporting the injection of the custom context is not available.

I propose that we log a warning message in JAXRSUtils.createContextValue if context value is null.
Does it sound reasonable ? And yes, we can support the injection of the CXF Sec context with ContextProvider. 


was (Author: sergey_beryozkin):
Hi Andrei

We have standard JAX-RS contexts - this must be supported.
CXF also supports the injection of custom context classes but it has to be in turn supported by additional ContextProvider providers but it is an out of the box support, it is optional depending on the availability of such providers. So if CXF-specifc SecurityContext needs to be injected then ContextProvider provider returning CXF SecurityContext needs to be registered.

I'm not sure we should prevent NPE - if it happens then it is a bug - either on CXF side or on the user side, for example, ContextProvider supporting the injection of the custom context is not available.

I propose that we log a warning message in JAXRSUtils.createContextValue if context value is null.
Does it sound reasonable ? And yes, we can support the injection of the CXF Sec context with ContextProvider. 

> Injection of SecurityContext
> ----------------------------
>
>                 Key: CXF-5803
>                 URL: https://issues.apache.org/jira/browse/CXF-5803
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS
>    Affects Versions: 2.7.11
>            Reporter: Andrei Shakirin
>            Assignee: Andrei Shakirin
>
> Currently two different SecurityContext interfaces are available in CXF:
> a) standard java: javax.ws.rs.core.SecurityContext
> b) internal CXF: org.apache.cxf.security.SecurityContext
> Context injection using @Context annotation works only for standard one. If user purposely or deliberately tries to inject internal CXF SecurityContext, access to it caused not very informative NLP:
> {code}
> Caused by: java.lang.NullPointerException
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.apache.cxf.jaxrs.impl.tl.ThreadLocalInvocationHandler.invoke(ThreadLocalInvocationHandler.java:36)
> 	at com.sun.proxy.$Proxy5.getUserPrincipal(Unknown Source)
> 	at demo.rs.security.SimpleCustomerService.getCustomer(SimpleCustomerService.java:26)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:181)
> 	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:97)
> 	... 26 more
> {code}
> I would propose either to support injections of both contexts or provide more clear error message.



--
This message was sent by Atlassian JIRA
(v6.2#6252)