2

I am attempting to make a CORS request to a Tomcat-hosted web-app (details below).

I have set up the CORS header stuff (in Apache httpd.conf) and it appears to be working, but the pre-flight OPTIONS request generated (I assume) by Chrome, which rightfully has no auth header, is failing with error 401.

I think I need to convince Apache or Tomcat not to do any auth for the OPTIONS request, but rather, to complete it with 200.

1) am I barking up the right tree?
2) Should I put a CORS filter in Tomcat (web.xml) instead of a set of Header Sets in Apache (httpd.conf)?
3) I can't find how to config apache to do that - any pointers? Closest hint I've found is @Thomas Broyer in April last year responding to Enable CORS for tomcat applications with credentials support thus:

you have to declare a <security-constraint> with <http-method>OPTIONS</http-method> and no <auth-constraint>."

Any help is greatly appreciated! I'm into multiple days trying to solve this...

===================

Current state of play:

Request:

Remote Address:54.245.121.9:80
Request URL:http://ec2-54-245-121-9.us-west-2.compute.amazonaws.com/v1/plant
Request Method:OPTIONS
Status Code:401 Unauthorized
Request Headersview parsed
OPTIONS /v1/plant HTTP/1.1
Host: ec2-54-245-121-9.us-west-2.compute.amazonaws.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://ec2-54-245-121-9.us-west-2.compute.amazonaws.com:8084
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Access-Control-Request-Headers: accept, authorization, content-type
Accept: */*
Referer: http://ec2-54-245-121-9.us-west-2.compute.amazonaws.com:8084/add
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,de;q=0.6

Response:

Headersview parsed
HTTP/1.1 401 Unauthorized
Date: Thu, 29 Jan 2015 23:00:34 GMT
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
WWW-Authenticate: Basic realm="Realm"
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1104
Access-Control-Allow-Origin: http://ec2-54-245-121-9.us-west-2.compute.amazonaws.com:8084
Vary: Origin
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: origin, accept, authorization, content-type, x-requested-with
Access-Control-Allow-Credentials: true
Connection: close

==============================

More about my app:

I have a MEAN web-app with the node.js server running on :8084.

There is an existing Tomcat/Java web-app with a REST API running on :80 (front-ended by Apache)...

The Angular.js-based js code in the client (in Chrome in my testing) is calling the REST API.

Because port 8084 != port 80, it's a CORS request.

Community
  • 1
  • 1
Doug Bergh
  • 53
  • 5
  • The Tomcat CORS filter flowchart at http://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png says that if it discovers that the request is a preflight, and everything is copacetic, it 'rewinds the filter chain'. Perhaps that's the answer...further processing, i.e. auth, does not happen? – Doug Bergh Jan 30 '15 at 02:30

2 Answers2

0

The Tomcat CORS filter flowchart at tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png says that if it discovers that the request is a preflight, and everything is copacetic, it 'rewinds the filter chain'. That implies that further processing -- like auth -- is not performed. So the answer appears to be to use the org.apache.catalina.filters.CorsFilter rather than inserting headers via httpd.conf.

Doug Bergh
  • 53
  • 5
0

Maybe this answer can help. In short:

<security-constraint>
    <web-resource-collection>
        <url-pattern>/*</url-pattern>
        <http-method>OPTIONS</http-method>
    </web-resource-collection>
    <!-- no auth-constraint here -->
</security-constraint>
Mladen B.
  • 2,784
  • 2
  • 23
  • 34