You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@gmail.com> on 2011/11/07 05:04:43 UTC
CORS
Has anyone considered adding CORS (http://www.w3.org/TR/cors/) to CXF
REST services? Obviously, it could be coded one service at a time, but
it looks handy.
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
Very good, thanks,
On 11/11/11 19:46, sergkorney wrote:
> Thank you very much for the hint. I have added initial draft to support
> handling authenticated CORS requests for GET methods. And it works just fine
> (with cxf 2.5.0).
> Here is jaxrs input filter :
>
> public class JaxrsCorsInputFilter implements RequestHandler {
>
> final static String HEADER_ORIGIN = "origin";
>
> @Context
> private HttpHeaders headers;
>
> @Override
> public Response handleRequest(Message m, ClassResourceInfo resourceClass) {
> if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
> return Response.status(Status.SERVICE_UNAVAILABLE).build();
> }
> List<String> values = headers.getRequestHeader(HEADER_ORIGIN);
> if (values != null ) {
Can you please prototype some example code here, instead of "if (true) ?
> if (true) {//check here if request came from allowed origin
> m.getExchange().put(HEADER_ORIGIN, values);
> }
> }
>
> return null;
> }
>
> }
>
>
> And here is jaxrs output filter:
>
> public class JaxrsCorsOutputFilter implements ResponseHandler {
>
> private final static String HEADER_AC_ALLOW_ORIGIN =
> "Access-Control-Allow-Origin";
> private final static String HEADER_AC_ALLOW_CREDENTIALS =
> "Access-Control-Allow-Credentials";
> private final static String HEADER_AC_EXPOSE_HEADERS =
> "Access-Control-Expose-Headers";
>
> @Override
> public Response handleResponse(Message m, OperationResourceInfo ori,
> Response response) {
> Object objOrigin =
> m.getExchange().get(JaxrsCorsInputFilter.HEADER_ORIGIN);
> if (objOrigin instanceof List<?> ) {
> List<String> origin = (List<String>) objOrigin;
> Map<String, List<String>> headers = (Map<String,
> List<String>>)m.get(Message.PROTOCOL_HEADERS);
> if (headers == null) {
> headers = new TreeMap<String,
> List<String>>(String.CASE_INSENSITIVE_ORDER);
> m.put(Message.PROTOCOL_HEADERS, headers);
> }
> headers.put(HEADER_AC_ALLOW_ORIGIN, origin);
> headers.put(HEADER_AC_ALLOW_CREDENTIALS, Arrays.asList(new
> String[]{"true"}));
> headers.put(HEADER_AC_EXPOSE_HEADERS, Arrays.asList(new
> String[]{"GET"}));
> }
> return response;
> }
>
> }
>
I think at this stage I will add a section dedicated to CORS to the wiki
and copy this code there, this is what we did originally for JSONP
before moving it to the trunk, I'd just need to prepare myself a bit
better to in order to understand what can be configured there, etc;
Please replace if(true) with a more specific code and we will proceed
from there
Cheers, Sergey
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CORS-tp4970153p4985376.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CORS
Posted by Benson Margulies <bi...@gmail.com>.
The code doesn't quite work as you expect.
If there is no origin header at all, the input filter gets an empty
array, not a null, so it does the wrong thing.
On Sat, Nov 12, 2011 at 2:35 AM, K Fung <kf...@gmail.com> wrote:
> Hello,
>
> Are there any plans to expand this code so that covers both 5.1 and 5.2 of
> the CORS specification (http://www.w3.org/TR/cors?) In particular,
>
> - Not blocking the request of it's an OPTIONS request but doesn't contain
> the Origin header
> - What if the request doesn't contain OPTIONS but does contain the Origin
> header (section 5.1 of the spec)
> - Adding support for Access-Control-Allow-Credentials (section 5.2 of the
> spec, step 7)
> - Adding support for Access-Control-Max-Age (section 5.2 of the spec, step
> 8)
>
> Cheers,
> kl
Re: CORS
Posted by Benson Margulies <bi...@gmail.com>.
I'd be happy to work on this code, but it *hasn't been contributed to
Apache yet.* It's not a patch, it has no Apache license, and isn't
attached to a JIRA.
On Wed, Nov 23, 2011 at 6:26 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
> I was thinking a bit more about it, we should probably just put it into
> org.apache.cxf.jaxrs.ext.cors in the jaxrs frontend at the moment, as I
> think that the creation of cxf-rt-jaxrs-extensions is needed shortly anyway
> which could keep most of the extensions, we can 'spawn' more specific
> modules from it as needed, I'd like to keep the web client api
> so it will live in its own extensions module, etc
>
> Sergey
>
> On 19/11/11 00:10, Benson Margulies wrote:
>>
>> OK, but attaching it to a JIRA still gives is clear provenance and we
>> can find it a home later.
>>
>> On Fri, Nov 18, 2011 at 11:48 AM, Sergey Beryozkin<sb...@gmail.com>
>> wrote:
>>>
>>> Hi Benson
>>> On 18/11/11 00:25, Benson Margulies wrote:
>>>>
>>>> Serg,
>>>>
>>>> To contribute code, it's preferred, if possible, to attach it to a JIRA.
>>>>
>>> I was thinking of simply documenting it for a start as I'm not sure where
>>> to
>>> add this code to. I guess I'd like it to go to a sep module but at this
>>> stage creating a module for keeping two simple filters may be a bit
>>> early.
>>> We can have another extension package added for a start to the rs
>>> frontend,
>>> and move it elsewhere, but I'm a bit cautious about it too as the
>>> frontend
>>> module is becoming quite monolitic and it will need to be split in time
>>> too,
>>> so I'm thinking that may be we just doc it and users will simply copy&
>>> paste the simple code, same way we started with JSONP code fragments.
>>>
>>>
>>> Sergey
>>>
>>>> --benson
>>>>
>>>>
>>>> On Thu, Nov 17, 2011 at 12:39 PM, sergkorney<se...@gmail.com>
>>>> wrote:
>>>>>
>>>>> here it is:
>>>>>
>>>>> public class JaxrsCorsInputFilter implements RequestHandler {
>>>>>
>>>>> final static String HEADER_ORIGIN = "origin";
>>>>>
>>>>> @Context
>>>>> private HttpHeaders headers;
>>>>>
>>>>> private List<String> allowedOrigins;
>>>>>
>>>>> public void setAllowedOrigins(List<String> allowedOrigins) {
>>>>> this.allowedOrigins = allowedOrigins;
>>>>> }
>>>>>
>>>>> @Override
>>>>> public Response handleRequest(Message m, ClassResourceInfo
>>>>> resourceClass) {
>>>>> if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
>>>>> OperationResourceInfo opResInfo =
>>>>> m.getExchange().get(OperationResourceInfo.class);
>>>>> if (opResInfo != null) { // OPTIONS method defined in
>>>>> service bean
>>>>> return null; // continue handling
>>>>> }
>>>>> return Response.status(Status.SERVICE_UNAVAILABLE).build();
>>>>> }
>>>>> List<String> values =
>>>>> headers.getRequestHeader(HEADER_ORIGIN);
>>>>> if (values != null ) {
>>>>> boolean allowed = true;
>>>>> if (allowedOrigins != null) {
>>>>> allowed = allowedOrigins.containsAll(values);
>>>>> }
>>>>> if (allowed) {
>>>>> m.getExchange().put(HEADER_ORIGIN, values);
>>>>> }
>>>>> }
>>>>> return null;
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
>>>>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> http://sberyozkin.blogspot.com
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>
>
>
> --
> Sergey Beryozkin
>
> http://sberyozkin.blogspot.com
>
> Talend Community Coders
> http://coders.talend.com/
>
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
I was thinking a bit more about it, we should probably just put it into
org.apache.cxf.jaxrs.ext.cors in the jaxrs frontend at the moment, as I
think that the creation of cxf-rt-jaxrs-extensions is needed shortly
anyway which could keep most of the extensions, we can 'spawn' more
specific modules from it as needed, I'd like to keep the web client api
so it will live in its own extensions module, etc
Sergey
On 19/11/11 00:10, Benson Margulies wrote:
> OK, but attaching it to a JIRA still gives is clear provenance and we
> can find it a home later.
>
> On Fri, Nov 18, 2011 at 11:48 AM, Sergey Beryozkin<sb...@gmail.com> wrote:
>> Hi Benson
>> On 18/11/11 00:25, Benson Margulies wrote:
>>>
>>> Serg,
>>>
>>> To contribute code, it's preferred, if possible, to attach it to a JIRA.
>>>
>> I was thinking of simply documenting it for a start as I'm not sure where to
>> add this code to. I guess I'd like it to go to a sep module but at this
>> stage creating a module for keeping two simple filters may be a bit early.
>> We can have another extension package added for a start to the rs frontend,
>> and move it elsewhere, but I'm a bit cautious about it too as the frontend
>> module is becoming quite monolitic and it will need to be split in time too,
>> so I'm thinking that may be we just doc it and users will simply copy&
>> paste the simple code, same way we started with JSONP code fragments.
>>
>>
>> Sergey
>>
>>> --benson
>>>
>>>
>>> On Thu, Nov 17, 2011 at 12:39 PM, sergkorney<se...@gmail.com> wrote:
>>>>
>>>> here it is:
>>>>
>>>> public class JaxrsCorsInputFilter implements RequestHandler {
>>>>
>>>> final static String HEADER_ORIGIN = "origin";
>>>>
>>>> @Context
>>>> private HttpHeaders headers;
>>>>
>>>> private List<String> allowedOrigins;
>>>>
>>>> public void setAllowedOrigins(List<String> allowedOrigins) {
>>>> this.allowedOrigins = allowedOrigins;
>>>> }
>>>>
>>>> @Override
>>>> public Response handleRequest(Message m, ClassResourceInfo
>>>> resourceClass) {
>>>> if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
>>>> OperationResourceInfo opResInfo =
>>>> m.getExchange().get(OperationResourceInfo.class);
>>>> if (opResInfo != null) { // OPTIONS method defined in
>>>> service bean
>>>> return null; // continue handling
>>>> }
>>>> return Response.status(Status.SERVICE_UNAVAILABLE).build();
>>>> }
>>>> List<String> values = headers.getRequestHeader(HEADER_ORIGIN);
>>>> if (values != null ) {
>>>> boolean allowed = true;
>>>> if (allowedOrigins != null) {
>>>> allowed = allowedOrigins.containsAll(values);
>>>> }
>>>> if (allowed) {
>>>> m.getExchange().put(HEADER_ORIGIN, values);
>>>> }
>>>> }
>>>> return null;
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
>>>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> http://sberyozkin.blogspot.com
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
Re: CORS
Posted by Benson Margulies <bi...@gmail.com>.
OK, but attaching it to a JIRA still gives is clear provenance and we
can find it a home later.
On Fri, Nov 18, 2011 at 11:48 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Benson
> On 18/11/11 00:25, Benson Margulies wrote:
>>
>> Serg,
>>
>> To contribute code, it's preferred, if possible, to attach it to a JIRA.
>>
> I was thinking of simply documenting it for a start as I'm not sure where to
> add this code to. I guess I'd like it to go to a sep module but at this
> stage creating a module for keeping two simple filters may be a bit early.
> We can have another extension package added for a start to the rs frontend,
> and move it elsewhere, but I'm a bit cautious about it too as the frontend
> module is becoming quite monolitic and it will need to be split in time too,
> so I'm thinking that may be we just doc it and users will simply copy &
> paste the simple code, same way we started with JSONP code fragments.
>
>
> Sergey
>
>> --benson
>>
>>
>> On Thu, Nov 17, 2011 at 12:39 PM, sergkorney<se...@gmail.com> wrote:
>>>
>>> here it is:
>>>
>>> public class JaxrsCorsInputFilter implements RequestHandler {
>>>
>>> final static String HEADER_ORIGIN = "origin";
>>>
>>> @Context
>>> private HttpHeaders headers;
>>>
>>> private List<String> allowedOrigins;
>>>
>>> public void setAllowedOrigins(List<String> allowedOrigins) {
>>> this.allowedOrigins = allowedOrigins;
>>> }
>>>
>>> @Override
>>> public Response handleRequest(Message m, ClassResourceInfo
>>> resourceClass) {
>>> if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
>>> OperationResourceInfo opResInfo =
>>> m.getExchange().get(OperationResourceInfo.class);
>>> if (opResInfo != null) { // OPTIONS method defined in
>>> service bean
>>> return null; // continue handling
>>> }
>>> return Response.status(Status.SERVICE_UNAVAILABLE).build();
>>> }
>>> List<String> values = headers.getRequestHeader(HEADER_ORIGIN);
>>> if (values != null ) {
>>> boolean allowed = true;
>>> if (allowedOrigins != null) {
>>> allowed = allowedOrigins.containsAll(values);
>>> }
>>> if (allowed) {
>>> m.getExchange().put(HEADER_ORIGIN, values);
>>> }
>>> }
>>> return null;
>>> }
>>>
>>> }
>>>
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
>>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>>
>
>
> --
> Sergey Beryozkin
>
> http://sberyozkin.blogspot.com
>
> Talend Community Coders
> http://coders.talend.com/
>
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Benson
On 18/11/11 00:25, Benson Margulies wrote:
> Serg,
>
> To contribute code, it's preferred, if possible, to attach it to a JIRA.
>
I was thinking of simply documenting it for a start as I'm not sure
where to add this code to. I guess I'd like it to go to a sep module but
at this stage creating a module for keeping two simple filters may be a
bit early.
We can have another extension package added for a start to the rs
frontend, and move it elsewhere, but I'm a bit cautious about it too as
the frontend module is becoming quite monolitic and it will need to be
split in time too, so I'm thinking that may be we just doc it and users
will simply copy & paste the simple code, same way we started with JSONP
code fragments.
Sergey
> --benson
>
>
> On Thu, Nov 17, 2011 at 12:39 PM, sergkorney<se...@gmail.com> wrote:
>> here it is:
>>
>> public class JaxrsCorsInputFilter implements RequestHandler {
>>
>> final static String HEADER_ORIGIN = "origin";
>>
>> @Context
>> private HttpHeaders headers;
>>
>> private List<String> allowedOrigins;
>>
>> public void setAllowedOrigins(List<String> allowedOrigins) {
>> this.allowedOrigins = allowedOrigins;
>> }
>>
>> @Override
>> public Response handleRequest(Message m, ClassResourceInfo resourceClass) {
>> if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
>> OperationResourceInfo opResInfo =
>> m.getExchange().get(OperationResourceInfo.class);
>> if (opResInfo != null) { // OPTIONS method defined in service bean
>> return null; // continue handling
>> }
>> return Response.status(Status.SERVICE_UNAVAILABLE).build();
>> }
>> List<String> values = headers.getRequestHeader(HEADER_ORIGIN);
>> if (values != null ) {
>> boolean allowed = true;
>> if (allowedOrigins != null) {
>> allowed = allowedOrigins.containsAll(values);
>> }
>> if (allowed) {
>> m.getExchange().put(HEADER_ORIGIN, values);
>> }
>> }
>> return null;
>> }
>>
>> }
>>
>>
>> --
>> View this message in context: http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/
Re: CORS
Posted by Benson Margulies <bi...@gmail.com>.
Serg,
To contribute code, it's preferred, if possible, to attach it to a JIRA.
--benson
On Thu, Nov 17, 2011 at 12:39 PM, sergkorney <se...@gmail.com> wrote:
> here it is:
>
> public class JaxrsCorsInputFilter implements RequestHandler {
>
> final static String HEADER_ORIGIN = "origin";
>
> @Context
> private HttpHeaders headers;
>
> private List<String> allowedOrigins;
>
> public void setAllowedOrigins(List<String> allowedOrigins) {
> this.allowedOrigins = allowedOrigins;
> }
>
> @Override
> public Response handleRequest(Message m, ClassResourceInfo resourceClass) {
> if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
> OperationResourceInfo opResInfo =
> m.getExchange().get(OperationResourceInfo.class);
> if (opResInfo != null) { // OPTIONS method defined in service bean
> return null; // continue handling
> }
> return Response.status(Status.SERVICE_UNAVAILABLE).build();
> }
> List<String> values = headers.getRequestHeader(HEADER_ORIGIN);
> if (values != null ) {
> boolean allowed = true;
> if (allowedOrigins != null) {
> allowed = allowedOrigins.containsAll(values);
> }
> if (allowed) {
> m.getExchange().put(HEADER_ORIGIN, values);
> }
> }
> return null;
> }
>
> }
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
Re: CORS
Posted by sergkorney <se...@gmail.com>.
here it is:
public class JaxrsCorsInputFilter implements RequestHandler {
final static String HEADER_ORIGIN = "origin";
@Context
private HttpHeaders headers;
private List<String> allowedOrigins;
public void setAllowedOrigins(List<String> allowedOrigins) {
this.allowedOrigins = allowedOrigins;
}
@Override
public Response handleRequest(Message m, ClassResourceInfo resourceClass) {
if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
OperationResourceInfo opResInfo =
m.getExchange().get(OperationResourceInfo.class);
if (opResInfo != null) { // OPTIONS method defined in service bean
return null; // continue handling
}
return Response.status(Status.SERVICE_UNAVAILABLE).build();
}
List<String> values = headers.getRequestHeader(HEADER_ORIGIN);
if (values != null ) {
boolean allowed = true;
if (allowedOrigins != null) {
allowed = allowedOrigins.containsAll(values);
}
if (allowed) {
m.getExchange().put(HEADER_ORIGIN, values);
}
}
return null;
}
}
--
View this message in context: http://cxf.547215.n5.nabble.com/CORS-tp4970153p5001897.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 12/11/11 07:35, K Fung wrote:
> Hello,
>
> Are there any plans to expand this code so that covers both 5.1 and 5.2 of
> the CORS specification (http://www.w3.org/TR/cors?) In particular,
>
> - Not blocking the request of it's an OPTIONS request but doesn't contain
> the Origin header
agreed, a JAX-RS resource class may also contain an @OPTIONS handler,
so the in filter should not block if the resource method has also been
selected, so if
message.getExchange().get(OperationResourceInfo.class)
returns a non-null value then it should let the request to continue
> - What if the request doesn't contain OPTIONS but does contain the Origin
> header (section 5.1 of the spec)
> - Adding support for Access-Control-Allow-Credentials (section 5.2 of the
> spec, step 7)
> - Adding support for Access-Control-Max-Age (section 5.2 of the spec, step
> 8)
>
Guess the support for the above can also added easily enough, good to
have so many CORS experts on the list :-)
Cheers, Sergey
> Cheers,
> kl
>
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 01/12/11 14:01, Benson Margulies wrote:
> I've created org.apache.cxf.jaxrs.cors.CrossOriginResourceSharingFilter,
> which is gradually learning to pass all the tests I'm figuring out to
> write. It is a complete implementation of the spec AFAICT.
Thanks Benson for doing it :-)
Cheers, Sergey
>
> On Sat, Nov 12, 2011 at 2:35 AM, K Fung<kf...@gmail.com> wrote:
>> Hello,
>>
>> Are there any plans to expand this code so that covers both 5.1 and 5.2 of
>> the CORS specification (http://www.w3.org/TR/cors?) In particular,
>>
>> - Not blocking the request of it's an OPTIONS request but doesn't contain
>> the Origin header
>> - What if the request doesn't contain OPTIONS but does contain the Origin
>> header (section 5.1 of the spec)
>> - Adding support for Access-Control-Allow-Credentials (section 5.2 of the
>> spec, step 7)
>> - Adding support for Access-Control-Max-Age (section 5.2 of the spec, step
>> 8)
>>
>> Cheers,
>> kl
Re: CORS
Posted by Benson Margulies <bi...@gmail.com>.
I've created org.apache.cxf.jaxrs.cors.CrossOriginResourceSharingFilter,
which is gradually learning to pass all the tests I'm figuring out to
write. It is a complete implementation of the spec AFAICT.
On Sat, Nov 12, 2011 at 2:35 AM, K Fung <kf...@gmail.com> wrote:
> Hello,
>
> Are there any plans to expand this code so that covers both 5.1 and 5.2 of
> the CORS specification (http://www.w3.org/TR/cors?) In particular,
>
> - Not blocking the request of it's an OPTIONS request but doesn't contain
> the Origin header
> - What if the request doesn't contain OPTIONS but does contain the Origin
> header (section 5.1 of the spec)
> - Adding support for Access-Control-Allow-Credentials (section 5.2 of the
> spec, step 7)
> - Adding support for Access-Control-Max-Age (section 5.2 of the spec, step
> 8)
>
> Cheers,
> kl
Re: CORS
Posted by K Fung <kf...@gmail.com>.
Hello,
Are there any plans to expand this code so that covers both 5.1 and 5.2 of
the CORS specification (http://www.w3.org/TR/cors?) In particular,
- Not blocking the request of it's an OPTIONS request but doesn't contain
the Origin header
- What if the request doesn't contain OPTIONS but does contain the Origin
header (section 5.1 of the spec)
- Adding support for Access-Control-Allow-Credentials (section 5.2 of the
spec, step 7)
- Adding support for Access-Control-Max-Age (section 5.2 of the spec, step
8)
Cheers,
kl
Re: CORS
Posted by sergkorney <se...@gmail.com>.
Thank you very much for the hint. I have added initial draft to support
handling authenticated CORS requests for GET methods. And it works just fine
(with cxf 2.5.0).
Here is jaxrs input filter :
public class JaxrsCorsInputFilter implements RequestHandler {
final static String HEADER_ORIGIN = "origin";
@Context
private HttpHeaders headers;
@Override
public Response handleRequest(Message m, ClassResourceInfo resourceClass) {
if ("OPTIONS".equals(m.get(Message.HTTP_REQUEST_METHOD))) {
return Response.status(Status.SERVICE_UNAVAILABLE).build();
}
List<String> values = headers.getRequestHeader(HEADER_ORIGIN);
if (values != null ) {
if (true) {//check here if request came from allowed origin
m.getExchange().put(HEADER_ORIGIN, values);
}
}
return null;
}
}
And here is jaxrs output filter:
public class JaxrsCorsOutputFilter implements ResponseHandler {
private final static String HEADER_AC_ALLOW_ORIGIN =
"Access-Control-Allow-Origin";
private final static String HEADER_AC_ALLOW_CREDENTIALS =
"Access-Control-Allow-Credentials";
private final static String HEADER_AC_EXPOSE_HEADERS =
"Access-Control-Expose-Headers";
@Override
public Response handleResponse(Message m, OperationResourceInfo ori,
Response response) {
Object objOrigin =
m.getExchange().get(JaxrsCorsInputFilter.HEADER_ORIGIN);
if (objOrigin instanceof List<?> ) {
List<String> origin = (List<String>) objOrigin;
Map<String, List<String>> headers = (Map<String,
List<String>>)m.get(Message.PROTOCOL_HEADERS);
if (headers == null) {
headers = new TreeMap<String,
List<String>>(String.CASE_INSENSITIVE_ORDER);
m.put(Message.PROTOCOL_HEADERS, headers);
}
headers.put(HEADER_AC_ALLOW_ORIGIN, origin);
headers.put(HEADER_AC_ALLOW_CREDENTIALS, Arrays.asList(new
String[]{"true"}));
headers.put(HEADER_AC_EXPOSE_HEADERS, Arrays.asList(new
String[]{"GET"}));
}
return response;
}
}
--
View this message in context: http://cxf.547215.n5.nabble.com/CORS-tp4970153p4985376.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 11/11/11 01:30, sergkorney wrote:
> Let start from adding JAX-RS CORS filter. I think mostly CORS support is
> really needed for RESTful services.
> I'm new to CXF but have some experience with using CORS filter mentioned
> here http://software.dzhuvinov.com/cors-filter.html
> http://software.dzhuvinov.com/cors-filter.html - Could you give me any hint
> how to setup a filter and get access inside it to all registered services,
> so that filter will handle OPTION requests only for registered services?
>
Sure, have a look at this section:
http://cxf.apache.org/docs/jax-rs-filters.html#JAX-RSFilters-Filters
Filters can get JAX-RS contexts injected, example, Headers, UriInfo,
Request or CXF MessageContext.
ClassResourceInfo represents a selected root resource, the fact the
filter is being invoked means that the JAX-RS runtime successfully
located a registered root resource which will handle the current request
URI... It's also possible to get to a resource Method which will
be invoked
Cheers, Sergey
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CORS-tp4970153p4982973.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CORS
Posted by sergkorney <se...@gmail.com>.
Let start from adding JAX-RS CORS filter. I think mostly CORS support is
really needed for RESTful services.
I'm new to CXF but have some experience with using CORS filter mentioned
here http://software.dzhuvinov.com/cors-filter.html
http://software.dzhuvinov.com/cors-filter.html - Could you give me any hint
how to setup a filter and get access inside it to all registered services,
so that filter will handle OPTION requests only for registered services?
--
View this message in context: http://cxf.547215.n5.nabble.com/CORS-tp4970153p4982973.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 07/11/11 14:39, Benson Margulies wrote:
> Why a filter? I guess, the advantage would be that it would work for
> SOAP and REST both. On the other hand, it's kind of 'over there'. Does
> JAX-RS have any other way to share out adding a handler for OPTIONS
> (and access control checking on Origin) that would have any
> advantages?
we can get a JAX-RS filter and a servlet filter sharing the same code,
this is what is done in the OAuth module
But I've had no experience with CORS so I'd need your help :-) We may
want to get filters and the supporting code located in in say a
cxf-rt-rs-security-cors module under rt/rs/security
Cheers, Sergey
>
> On Mon, Nov 7, 2011 at 9:10 AM, Sergey Beryozkin<sb...@gmail.com> wrote:
>> Hi Benson
>> On 07/11/11 04:04, Benson Margulies wrote:
>>>
>>> Has anyone considered adding CORS (http://www.w3.org/TR/cors/) to CXF
>>> REST services? Obviously, it could be coded one service at a time, but
>>> it looks handy.
>>
>> Can you look at
>> http://cxf.547215.n5.nabble.com/CORS-Interceptor-Filter-Endpoint-td4793366.html
>> please ?
>> Do you reckon we should ship a CXF specific CORS filter ?
>>
>> Thanks, Sergey
>>
Re: CORS
Posted by Benson Margulies <bi...@gmail.com>.
Why a filter? I guess, the advantage would be that it would work for
SOAP and REST both. On the other hand, it's kind of 'over there'. Does
JAX-RS have any other way to share out adding a handler for OPTIONS
(and access control checking on Origin) that would have any
advantages?
On Mon, Nov 7, 2011 at 9:10 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Benson
> On 07/11/11 04:04, Benson Margulies wrote:
>>
>> Has anyone considered adding CORS (http://www.w3.org/TR/cors/) to CXF
>> REST services? Obviously, it could be coded one service at a time, but
>> it looks handy.
>
> Can you look at
> http://cxf.547215.n5.nabble.com/CORS-Interceptor-Filter-Endpoint-td4793366.html
> please ?
> Do you reckon we should ship a CXF specific CORS filter ?
>
> Thanks, Sergey
>
Re: CORS
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Benson
On 07/11/11 04:04, Benson Margulies wrote:
> Has anyone considered adding CORS (http://www.w3.org/TR/cors/) to CXF
> REST services? Obviously, it could be coded one service at a time, but
> it looks handy.
Can you look at
http://cxf.547215.n5.nabble.com/CORS-Interceptor-Filter-Endpoint-td4793366.html
please ?
Do you reckon we should ship a CXF specific CORS filter ?
Thanks, Sergey