Environment Tomcat Server hosting webservice app. Website is built using SpringMVC and AngularJS.
Core issue: REST GET triggers OPTIONS request, which fails. The GET in question returns an application/JSON response. Initially, I got the error :
"Failed to load resource: the server responded with a status of 403 (Forbidden)
Failed to load http://myServer:8084/wsPRDE/navbar/getnavbartxt: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://myServer:8080' is therefore not allowed access. The response had HTTP status code 403."
Prior to this problem, all we did was have @CrossOrigin in our Controllers. Then httpd.conf was set to add those headers. Which it did for all the script-retrieving from the site (ironically not CORS) but not for the actual CORS responses. When I ensured Access-Control- Allow-Origin, Allow-Methods and Allow-Headers were returned in the response, by coding a CORSFilter into the webservice, the error changed to :
"OPTIONS http://myServer:8084/wsPOFA/navbar/getnavbartxt 403 (Forbidden) Failed to load http://myServer:8084/wsPOFA/navbar/getnavbartxt: Response for preflight has invalid HTTP status code 403."
Background: The error was detected in a rather random way. A process management colleague of mine had a windows 10 update. Since said update, the entire webservice fails because it can't be reached. Any request from the site itself to the webapplication (same address, different ports), fail. My superior (I'm an intern) then found that in Chrome and IE(when using Server alias, not when using the "normal" URL) have the same issue without the windows 10 update. Prior to the update (or when using IE with normal URL), the GET does not seem to trigger an OPTIONS request.
Further Attempts After this I've tried to expand the Allow-Headers to include all fields present in the GET request/response. I also compare the Origin in the OPTIONS request to a whitelist of Origins, setting the OPTIONS response Allow-Origin header value to the request Origin value if they match.
So the origins match and all the headers in the request/response are set to be allowed. I've spent 3 days so far reading up on CORS and looking for solutions on the web. Most solutions mention the CORS filter I've implemented, and then there are a ton of dirty-workarounds from clearing the header entirely, to always responding 200 OK to OPTIONS requests. But they seem very "dirty" solutions.
Can anyone point me in the right direction? Should I be looking at adding CORS-related code to my Spring Controllers? Is the delegation of constructing httpRequests to AngularJS the crux of my problems? Or am I thinking in the wrong direction entirely?
Currently, my request/response headers look like this:
200
as "dirty"? That is exactly what needs to be done. – georgeawg