Re: CORS: removing allowOrigins from the annotation only

[Sergey Beryozkin]

It appears that these 'difficulties' with allowAllOrigins & allowOrigins 
clearly indicate that the original Benson's idea to get one annotation 
per every property in [1] did have a lot of sense, however having the 
explosion of annotations seemed too much to me at the time.
That said, I did also move the localPreflight property into a dedicated 
annotation[2] as it does not seem to belong to the main [1]


Hope everyone is OK with it
Sergey

[1] 
http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/CrossOriginResourceSharing.java
[2] 
http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/cors/src/main/java/org/apache/cxf/rs/security/cors/LocalPreflight.java



On 14/03/12 11:22, Sergey Beryozkin wrote:

One thing I forgot to mention from the start that the easy option is
simply not to attach CrossOriginResourceSharing to a given resource
method, so the filter values will be used instead. I'm only really about
making sure that CrossOriginResourceSharing can still be used if
preferred while only allowOrigins can be configured internally in the
filter

Cheers, Sergey

On 14/03/12 11:19, Sergey Beryozkin wrote:

Hi Aki
On 14/03/12 11:12, Aki Yoshida wrote:

Hi Sergey,
I am not familiar with this stuff, so what I am saying may not make
sense, though :-)


thanks for the comments, they make sense :-)

But can you use the different default value so that you can
distinguish between the null (i.e., interpreted as
allowAllOrigins=true) and an empty allowOrigins (i.e.,
allowAllOrigins=false) ?



I was just about to press commit when I saw your message :-).
For the moment I restored that flag, as opposed to deleting the
allowOrigins completely, one the basis that all other
CrossOriginResourceSharing properties can equally be considered not
method specific, but the endpoint specific...
I briefly thought earlier on about the 'marker' value for allowOrigins,
but the allowOrigins is an array, so having some marker value would
probably complicate a bit the processing as one would need to also
consider the case where valid and a marker properties are mixed in...

Thanks, Sergey


regards, aki

2012/3/14 Sergey Beryozkin:

Hi Benson, all,

I've been modifying the CrossOriginResourceSharing annotation as well
as the
CrossOriginResourceSharingFilter during the last couple of days to
address
the issue reported by Matt Bishop, namely, to do with making it
possible to
avoid specifying "allowOrigins" within the CrossOriginResourceSharing
annotation, given that "allowOrigins" keeps the list of absolute URIs
thus
it is not ideal at all to have it declared in the actual code.

CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean
property set by default to 'false' and also the 'allowOrigins'
list/array
property, the latter was ignored if 'allowAllOrigins' was set to true.

Additionally, similar properties exist in
CrossOriginResourceSharingFilter
which can be effective when the annotation is not set on a given
method.

I started with removing what I thought was a redundant
CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an
empty/default 'allowOrigins' does mean 'allow all origins'.

The problem I'm seeing with this now that in order to be possible to
avoid
specifying specific 'allowOrigins' in the application code within
CrossOriginResourceSharing one has to choose not to use
CrossOriginResourceSharing because if it is provided it takes the
preference
over the possible custom values set in the filter.

So one option is to restore the boolean "allowAllOrigins" flag. By
default
it is set to 'false'. Thus if CrossOriginResourceSharing'
allowOrigins is
empty then there must be a filter property set customizing the
allowOrigins
to meet the allowAllOrigins==false requirement.

Another option is to remove CrossOriginResourceSharing' allowOrigins
and
expect the filter customize it when needed.
The idea here is that it appears to be unlikely various individual
methods
within a current JAX-RS endpoint may have different allowed origins,
rather
it's more likely that the allowOrigins are going to be shared by all
the
JAX-RS methods for a given endpoint.

So I kind of prefer the 2nd option but at the same time I'm OK with
restoring the flag for the sake of simplifying the testing and such
at a
minor cost of keeping the somewhat redundant 'allowAllOrigins'...

Let me know please what you think

Cheers, Sergey

Re: CORS: removing allowOrigins from the annotation only

[Sergey Beryozkin]

One thing I forgot to mention from the start that the easy option is 
simply not to attach CrossOriginResourceSharing to a given resource 
method, so the filter values will be used instead. I'm only really about 
making sure that CrossOriginResourceSharing can still be used if 
preferred while only allowOrigins can be configured internally in the filter


Cheers, Sergey

On 14/03/12 11:19, Sergey Beryozkin wrote:

Hi Aki
On 14/03/12 11:12, Aki Yoshida wrote:

Hi Sergey,
I am not familiar with this stuff, so what I am saying may not make
sense, though :-)


thanks for the comments, they make sense :-)

But can you use the different default value so that you can
distinguish between the null (i.e., interpreted as
allowAllOrigins=true) and an empty allowOrigins (i.e.,
allowAllOrigins=false) ?



I was just about to press commit when I saw your message :-).
For the moment I restored that flag, as opposed to deleting the
allowOrigins completely, one the basis that all other
CrossOriginResourceSharing properties can equally be considered not
method specific, but the endpoint specific...
I briefly thought earlier on about the 'marker' value for allowOrigins,
but the allowOrigins is an array, so having some marker value would
probably complicate a bit the processing as one would need to also
consider the case where valid and a marker properties are mixed in...

Thanks, Sergey


regards, aki

2012/3/14 Sergey Beryozkin:

Hi Benson, all,

I've been modifying the CrossOriginResourceSharing annotation as well
as the
CrossOriginResourceSharingFilter during the last couple of days to
address
the issue reported by Matt Bishop, namely, to do with making it
possible to
avoid specifying "allowOrigins" within the CrossOriginResourceSharing
annotation, given that "allowOrigins" keeps the list of absolute URIs
thus
it is not ideal at all to have it declared in the actual code.

CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean
property set by default to 'false' and also the 'allowOrigins'
list/array
property, the latter was ignored if 'allowAllOrigins' was set to true.

Additionally, similar properties exist in
CrossOriginResourceSharingFilter
which can be effective when the annotation is not set on a given method.

I started with removing what I thought was a redundant
CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an
empty/default 'allowOrigins' does mean 'allow all origins'.

The problem I'm seeing with this now that in order to be possible to
avoid
specifying specific 'allowOrigins' in the application code within
CrossOriginResourceSharing one has to choose not to use
CrossOriginResourceSharing because if it is provided it takes the
preference
over the possible custom values set in the filter.

So one option is to restore the boolean "allowAllOrigins" flag. By
default
it is set to 'false'. Thus if CrossOriginResourceSharing'
allowOrigins is
empty then there must be a filter property set customizing the
allowOrigins
to meet the allowAllOrigins==false requirement.

Another option is to remove CrossOriginResourceSharing' allowOrigins and
expect the filter customize it when needed.
The idea here is that it appears to be unlikely various individual
methods
within a current JAX-RS endpoint may have different allowed origins,
rather
it's more likely that the allowOrigins are going to be shared by all the
JAX-RS methods for a given endpoint.

So I kind of prefer the 2nd option but at the same time I'm OK with
restoring the flag for the sake of simplifying the testing and such at a
minor cost of keeping the somewhat redundant 'allowAllOrigins'...

Let me know please what you think

Cheers, Sergey

Re: CORS: removing allowOrigins from the annotation only

[Sergey Beryozkin]

Hi Aki
On 14/03/12 11:12, Aki Yoshida wrote:

Hi Sergey,
I am not familiar with this stuff, so what I am saying may not make
sense, though :-)


thanks for the comments, they make sense :-)

But can you use the different default value so that you can
distinguish between the null (i.e., interpreted as
allowAllOrigins=true) and an empty allowOrigins  (i.e.,
allowAllOrigins=false) ?



I was just about to press commit when I saw your message :-).
For the moment I restored that flag, as opposed to deleting the 
allowOrigins completely, one the basis that all other 
CrossOriginResourceSharing properties can equally be considered not 
method specific, but the endpoint specific...
I briefly thought earlier on about the 'marker' value for allowOrigins, 
but the allowOrigins is an array, so having some marker value would 
probably complicate a bit the processing as one would need to also 
consider the case where valid and a marker properties are mixed in...


Thanks, Sergey


regards, aki

2012/3/14 Sergey Beryozkin:

Hi Benson, all,

I've been modifying the CrossOriginResourceSharing annotation as well as the
CrossOriginResourceSharingFilter during the last couple of days to address
the issue reported by Matt Bishop, namely, to do with making it possible to
avoid specifying "allowOrigins" within the CrossOriginResourceSharing
annotation, given that "allowOrigins" keeps the list of absolute URIs thus
it is not ideal at all to have it declared in the actual code.

CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean
property set by default to 'false' and also the 'allowOrigins' list/array
property, the latter was ignored if 'allowAllOrigins' was set to true.

Additionally, similar properties exist in CrossOriginResourceSharingFilter
which can be effective when the annotation is not set on a given method.

I started with removing what I thought was a redundant
CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an
empty/default 'allowOrigins' does mean 'allow all origins'.

The problem I'm seeing with this now that in order to be possible to avoid
specifying specific 'allowOrigins' in the application code within
CrossOriginResourceSharing one has to choose not to use
CrossOriginResourceSharing because if it is provided it takes the preference
over the possible custom values set in the filter.

So one option is to restore the boolean "allowAllOrigins" flag. By default
it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is
empty then there must be a filter property set customizing the allowOrigins
to meet the allowAllOrigins==false requirement.

Another option is to remove CrossOriginResourceSharing' allowOrigins and
expect the filter customize it when needed.
The idea here is that it appears to be unlikely various individual methods
within a current JAX-RS endpoint may have different allowed origins, rather
it's more likely that the allowOrigins are going to be shared by all the
JAX-RS methods for a given endpoint.

So I kind of prefer the 2nd option but at the same time I'm OK with
restoring the flag for the sake of simplifying the testing and such at a
minor cost of keeping the somewhat redundant 'allowAllOrigins'...

Let me know please what you think

Cheers, Sergey







--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: CORS: removing allowOrigins from the annotation only

[Aki Yoshida]

Hi Sergey,
I am not familiar with this stuff, so what I am saying may not make
sense, though :-)

But can you use the different default value so that you can
distinguish between the null (i.e., interpreted as
allowAllOrigins=true) and an empty allowOrigins  (i.e.,
allowAllOrigins=false) ?

regards, aki

2012/3/14 Sergey Beryozkin :
> Hi Benson, all,
>
> I've been modifying the CrossOriginResourceSharing annotation as well as the
> CrossOriginResourceSharingFilter during the last couple of days to address
> the issue reported by Matt Bishop, namely, to do with making it possible to
> avoid specifying "allowOrigins" within the CrossOriginResourceSharing
> annotation, given that "allowOrigins" keeps the list of absolute URIs thus
> it is not ideal at all to have it declared in the actual code.
>
> CrossOriginResourceSharing used to have an 'allowAllOrigins' boolean
> property set by default to 'false' and also the 'allowOrigins' list/array
> property, the latter was ignored if 'allowAllOrigins' was set to true.
>
> Additionally, similar properties exist in CrossOriginResourceSharingFilter
> which can be effective when the annotation is not set on a given method.
>
> I started with removing what I thought was a redundant
> CrossOriginResourceSharing 'allowAllOrigins', instead assuming that an
> empty/default 'allowOrigins' does mean 'allow all origins'.
>
> The problem I'm seeing with this now that in order to be possible to avoid
> specifying specific 'allowOrigins' in the application code within
> CrossOriginResourceSharing one has to choose not to use
> CrossOriginResourceSharing because if it is provided it takes the preference
> over the possible custom values set in the filter.
>
> So one option is to restore the boolean "allowAllOrigins" flag. By default
> it is set to 'false'. Thus if CrossOriginResourceSharing' allowOrigins is
> empty then there must be a filter property set customizing the allowOrigins
> to meet the allowAllOrigins==false requirement.
>
> Another option is to remove CrossOriginResourceSharing' allowOrigins and
> expect the filter customize it when needed.
> The idea here is that it appears to be unlikely various individual methods
> within a current JAX-RS endpoint may have different allowed origins, rather
> it's more likely that the allowOrigins are going to be shared by all the
> JAX-RS methods for a given endpoint.
>
> So I kind of prefer the 2nd option but at the same time I'm OK with
> restoring the flag for the sake of simplifying the testing and such at a
> minor cost of keeping the somewhat redundant 'allowAllOrigins'...
>
> Let me know please what you think
>
> Cheers, Sergey
>
>
>
>

Re: CORS documentation

[Satheesh Chinthapatla]

Thanks for reply.

CXF general is fine, Let me go through the link below provided

Regards
Satish

On Thu, Jan 19, 2012 at 5:01 PM, Sergey Beryozkin wrote:

> Hi
>
>
> On 19/01/12 20:38, Satheesh Chinthapatla wrote:
>
>> Hello All,
>>
>> I would like to contribute some thing into this project but I am not
>> sure where to start since I am very new in contributing into open
>> source.
>>
>> About me:
>>
>> I am lead java developer having 12 yrs of experience and currently
>> working in NJ.
>>
>>
> Are you interested in contributing specifically to the CORS effort or to
> CXF in general ?
> Please check
> http://cxf.apache.org/getting-**involved.html
>
> and then if it is CORS then I think what should help is experimenting with
> what we already have, testing it with different browsers, and submitting
> patches if needed
>
> Thanks, Sergey
>
>
>  Thanks
>> Satish
>>
>>
>>
>> On Jan 19, 2012, at 3:11 PM, Benson 
>> Margulies>
>>  wrote:
>>
>>  Sorry, I've been marginally sick and that has stopped me from making
>>> it to this task. I did try to write a lot of javadoc.
>>>
>>> On Thu, Jan 19, 2012 at 1:19 PM, Sergey Beryozkin
>>>  wrote:
>>>
 On 06/01/12 11:50, Sergey Beryozkin wrote:

>
> Hi Benson
>
> I've created a page for documenting the initial CORS support,
> https://cwiki.apache.org/**confluence/display/CXF20DOC/**JAX-RS+CORS
>
> if you get a chance, fill it in please; I can contribute too but a bit
> later
>


 I started putting some code examples from the tests you did, which is a
 start. The package.html is also very good, I have a couple of minor
 changes,
 will commit a bit later.
 It seems we have some good support for people to start experimenting
 with
 CORS,

 By the way I'm planning to move the CORS code into a dedicated module as
 it's very likely to grow

 Cheers, Sergey

>>>

Re: CORS documentation

[Sergey Beryozkin]

Hi

On 19/01/12 20:38, Satheesh Chinthapatla wrote:

Hello All,

I would like to contribute some thing into this project but I am not
sure where to start since I am very new in contributing into open
source.

About me:

I am lead java developer having 12 yrs of experience and currently
working in NJ.



Are you interested in contributing specifically to the CORS effort or to 
CXF in general ?

Please check
http://cxf.apache.org/getting-involved.html

and then if it is CORS then I think what should help is experimenting 
with what we already have, testing it with different browsers, and 
submitting patches if needed


Thanks, Sergey


Thanks
Satish



On Jan 19, 2012, at 3:11 PM, Benson Margulies  wrote:


Sorry, I've been marginally sick and that has stopped me from making
it to this task. I did try to write a lot of javadoc.

On Thu, Jan 19, 2012 at 1:19 PM, Sergey Beryozkin  wrote:

On 06/01/12 11:50, Sergey Beryozkin wrote:


Hi Benson

I've created a page for documenting the initial CORS support,
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS

if you get a chance, fill it in please; I can contribute too but a bit
later



I started putting some code examples from the tests you did, which is a
start. The package.html is also very good, I have a couple of minor changes,
will commit a bit later.
It seems we have some good support for people to start experimenting with
CORS,

By the way I'm planning to move the CORS code into a dedicated module as
it's very likely to grow

Cheers, Sergey

Re: CORS documentation

[Sergey Beryozkin]

On 19/01/12 20:10, Benson Margulies wrote:

Sorry, I've been marginally sick and that has stopped me from making
it to this task. I did try to write a lot of javadoc.



It is all very well documented, thanks...

Cheers, Sergey


On Thu, Jan 19, 2012 at 1:19 PM, Sergey Beryozkin  wrote:

On 06/01/12 11:50, Sergey Beryozkin wrote:


Hi Benson

I've created a page for documenting the initial CORS support,
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS

if you get a chance, fill it in please; I can contribute too but a bit
later



I started putting some code examples from the tests you did, which is a
start. The package.html is also very good, I have a couple of minor changes,
will commit a bit later.
It seems we have some good support for people to start experimenting with
CORS,

By the way I'm planning to move the CORS code into a dedicated module as
it's very likely to grow

Cheers, Sergey



--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: CORS documentation

[Satheesh Chinthapatla]

Hello All,

I would like to contribute some thing into this project but I am not
sure where to start since I am very new in contributing into open
source.

About me:

I am lead java developer having 12 yrs of experience and currently
working in NJ.

Thanks
Satish



On Jan 19, 2012, at 3:11 PM, Benson Margulies  wrote:

> Sorry, I've been marginally sick and that has stopped me from making
> it to this task. I did try to write a lot of javadoc.
>
> On Thu, Jan 19, 2012 at 1:19 PM, Sergey Beryozkin  
> wrote:
>> On 06/01/12 11:50, Sergey Beryozkin wrote:
>>>
>>> Hi Benson
>>>
>>> I've created a page for documenting the initial CORS support,
>>> https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS
>>>
>>> if you get a chance, fill it in please; I can contribute too but a bit
>>> later
>>
>>
>> I started putting some code examples from the tests you did, which is a
>> start. The package.html is also very good, I have a couple of minor changes,
>> will commit a bit later.
>> It seems we have some good support for people to start experimenting with
>> CORS,
>>
>> By the way I'm planning to move the CORS code into a dedicated module as
>> it's very likely to grow
>>
>> Cheers, Sergey

Re: CORS documentation

[Benson Margulies]

Sorry, I've been marginally sick and that has stopped me from making
it to this task. I did try to write a lot of javadoc.

On Thu, Jan 19, 2012 at 1:19 PM, Sergey Beryozkin  wrote:
> On 06/01/12 11:50, Sergey Beryozkin wrote:
>>
>> Hi Benson
>>
>> I've created a page for documenting the initial CORS support,
>> https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS
>>
>> if you get a chance, fill it in please; I can contribute too but a bit
>> later
>
>
> I started putting some code examples from the tests you did, which is a
> start. The package.html is also very good, I have a couple of minor changes,
> will commit a bit later.
> It seems we have some good support for people to start experimenting with
> CORS,
>
> By the way I'm planning to move the CORS code into a dedicated module as
> it's very likely to grow
>
> Cheers, Sergey

Re: CORS documentation

[Sergey Beryozkin]

On 06/01/12 11:50, Sergey Beryozkin wrote:

Hi Benson

I've created a page for documenting the initial CORS support,
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+CORS

if you get a chance, fill it in please; I can contribute too but a bit
later


I started putting some code examples from the tests you did, which is a 
start. The package.html is also very good, I have a couple of minor 
changes, will commit a bit later.
It seems we have some good support for people to start experimenting 
with CORS,


By the way I'm planning to move the CORS code into a dedicated module as 
it's very likely to grow


Cheers, Sergey

Re: CORS filter a bit noisy

[Sergey Beryozkin]

On 21/12/11 22:23, Sergey Beryozkin wrote:

Hi Benson
On 21/12/11 18:32, Benson Margulies wrote:

It looks to me as if the CORS filter has a bug: it returns headers
even when the request is not cross-origin. Sergey, WTYT? I'm sure it's
not a tragedy and that I could fix that easily enough.

Which headers are you referring to, the ones that are returned as part
of the SIMPLE request post-processing or some other headers ?

Oh, you mean the usual plain requests, right ? Thought in the code the 
cors filter does not do anything in such cases on the output and just 
returns




Cheers, Sergey

Re: CORS filter a bit noisy

[Sergey Beryozkin]

Hi Benson
On 21/12/11 18:32, Benson Margulies wrote:

It looks to me as if the CORS filter has a bug: it returns headers
even when the request is not cross-origin. Sergey, WTYT? I'm sure it's
not a tragedy and that I could fix that easily enough.
Which headers are you referring to, the ones that are returned as part 
of the SIMPLE request post-processing or some other headers ?


Cheers, Sergey

Re: CORS

[Sergey Beryozkin]

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  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

[Benson Margulies]

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  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

[Benson Margulies]

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  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

[Benson Margulies]

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  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
>>  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
  wrote:
>
> here it is:
>
> public class JaxrsCorsInputFilter implements RequestHandler {
>
>        final static String HEADER_ORIGIN = "origin";
>
>        @Context
>    private HttpHeaders headers;
>
>        private List    allowedOrigins;
>
>    public void setAllowedOrigins(List    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    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

[Sergey Beryozkin]

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  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, sergkorneywrote:


here it is:

public class JaxrsCorsInputFilter implements RequestHandler {

final static String HEADER_ORIGIN = "origin";

@Context
private HttpHeaders headers;

private ListallowedOrigins;

public void setAllowedOrigins(ListallowedOrigins) {
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();
}
Listvalues = 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

[Benson Margulies]

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  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  wrote:
>>>
>>> here it is:
>>>
>>> public class JaxrsCorsInputFilter implements RequestHandler {
>>>
>>>        final static String HEADER_ORIGIN = "origin";
>>>
>>>        @Context
>>>    private HttpHeaders headers;
>>>
>>>        private List  allowedOrigins;
>>>
>>>    public void setAllowedOrigins(List  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  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

[Sergey Beryozkin]

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  wrote:

here it is:

public class JaxrsCorsInputFilter implements RequestHandler {

final static String HEADER_ORIGIN = "origin";

@Context
private HttpHeaders headers;

private List  allowedOrigins;

public void setAllowedOrigins(List  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  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

[Benson Margulies]

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  wrote:
> here it is:
>
> public class JaxrsCorsInputFilter implements RequestHandler {
>
>        final static String HEADER_ORIGIN = "origin";
>
>        @Context
>    private HttpHeaders headers;
>
>        private List allowedOrigins;
>
>    public void setAllowedOrigins(List 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 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

[sergkorney]

here it is:

public class JaxrsCorsInputFilter implements RequestHandler {

final static String HEADER_ORIGIN = "origin";

@Context
private HttpHeaders headers;

private List allowedOrigins;

public void setAllowedOrigins(List 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 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

[Sergey Beryozkin]

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

[Sergey Beryozkin]

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  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  origin = (List) objOrigin;
Map>  headers = (Map>)m.get(Message.PROTOCOL_HEADERS);
if (headers == null) {
headers = new TreeMap>(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

[K Fung]

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

[sergkorney]

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 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 origin = (List) objOrigin;
Map> headers = (Map>)m.get(Message.PROTOCOL_HEADERS);
if (headers == null) {
headers = new TreeMap>(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

[Sergey Beryozkin]

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

[sergkorney]

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

[Sergey Beryozkin]

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  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

[Benson Margulies]

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  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

[Sergey Beryozkin]

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