CORS Filter in JerseyExample project does not catch all Preflight requests about bytefish.de HOT 10 CLOSED

By the way, could you make the example project public or point me to where I can find it? I was not successful when looking for it at GitHub.

from bytefish.de.

Oh you are right, it is not on GitHub. I thought I had published it. I will try to create a repository it this weekend. The code is still in a private repository with code I don't want to publish. 😅 Probably something is missing in my blog post, I will double check it this weekend.

from bytefish.de.

Back to my original question am I right or missing someting?

I was wondering if it was a possibility to process preflight requests in the filter, too. Currently you're explicitely excepting the preflight request from the processing in the CrossOriginRepsonseFilter and relocating the work to the BaseResource. Which in my opinion leads to the fact that you can not use the @path annotation in its full extent for methods like described above.
But if you process the Preflight requests also in the filter you could just alter the status code to 200 if a resource has not been found or if OPTIONS is not an allowed method. I'm not sure if that works or if Jersey will just not use the filter in the error case. What do you think about that idea?

from bytefish.de.

Well actually I just noticed that Jersey creates a standard OPTIONS handler for every existing path. So why make the difference for preflight requests and others in the filter at all? Could we not just set the CORS filter in general or maybe if that interferes with the Annotation-Logic in a separate second filter?

from bytefish.de.

You are correct I think, no you are not missing something. When looking at the code now, I guess a CORS Filter would be totally sufficient and the Base Resource is obsolete (and probably leads to problems with Paths like you mentioned).

Thanks for the hints, I will refactor it and update the blog article accordingly.

from bytefish.de.

Cool, thanks for the answer!

from bytefish.de.

Just wanted to let you know, that there is a shortcomming of my suggestion, that I just encountered:
The annotation @crossorigin won't work because the name binding will not be transferred to the autogenerated OPTIONS handlers.
However I wonder If you would have to add the @CrossOrigin-annotation to your BaseResource. Actually I did not try your solution with the annotation, I just left that out.

from bytefish.de.

I will create a sample project with proper tests, but right now I have a busy work schedule so I can't make promises. I think you are right, my solution probably has shortcomings with Paths. But if you annotate an Endpoint with the CrossOrigin Annotation it should work, and if it is urgent it may be a temporary workaround.

from bytefish.de.

@szauner You were totally right. I accidentally attributed all my endpoints with the @CrossOrigin attribute, so the requests to the specific endpoint always had the CORS headers. The catch-all endpoint was never hit, which again highlights the importance of Integration Tests. Sadly I do not have time to fix this in a way an implementation would fully cover the CORS specification. And it is not useful to throw out half-baked solutions.

So I have deleted the blog post to not spread wrong information.

Thanks again for notifying me!

I hope you are not too disappointed with me, but I simply have no time.

from bytefish.de.

Hi, no no I am not disappointed at all. I thank you very much for the clarification we reached ;-)

from bytefish.de.