3

I am currently confused about how angular's (jquery) preflight OPTIONS call is "selected" or chosen to perform before a request.

I have a normal RESTful api call (api.domain.co)

I have created a host entry 127.0.0.1 local.domain.co in my hosts file /etc/hosts.

I've created self-signed certificate:

http://www.akadia.com/services/ssh_test_certificate.html

I've configured the certs in my mac as trusted:

http://abetobing.com/blog/port-forwarding-mac-os-yosemite-81.html

I've configured my Yosemite Port Forwarding Rules:

http://abetobing.com/blog/port-forwarding-mac-os-yosemite-81.html

I understand that from the browser's perspective (Chrome):

I have an angular app being loaded from https://local.domain.co with a trusted certificate that has a call to https://api.domain.co/user everything looks green with the cert, and I still get a preflight OPTIONS call to my api.domain.co server which is a node resitfy server with CORS support

Everything is Working... BUT

I want to get rid of the OPTIONS preflight Any pointers?

Franky Diaz-Trepat
  • 31
  • 1
  • 4
  • UPDATE - BAD NEWS on the actual server with domain myapp.domain.co api.domain.co is generating preflight OPTION calls. From the same server. – Franky Diaz-Trepat Jun 10 '15 at 22:01

2 Answers2

1

unfortunately subdomain still affected by preflight rule so if you want to remove OPTIONS you can either using jsonp or have the same subdomain for both the site & api.

kwangsa
  • 1,701
  • 12
  • 16
0

You can't use localhost. I had to create an entry in my host file to associate 127.0.0.1 to an arbitrary name like mackbook. Then it should work for you.

Jeffrey A. Gochin
  • 964
  • 6
  • 18
  • The 4th line says exactly that. – Franky Diaz-Trepat Jun 08 '15 at 01:22
  • Does the REST server know your host name of local.domain.co. In other words is local.domain.co a trusted host name with the REST server? – Jeffrey A. Gochin Jun 08 '15 at 01:51
  • Yes, that is why the cors preflight and everything else is working fine. I just want to get rid of the preflight OPTIONS calls and I fear that even coming from the same server, it could be that api.domain.com and app.domain.com evaluate as cross domains. It might be needed HOPE NOT that api needs to be behind the .com like app.domain.com/rest-api. This last part sounds ridiculous, it is just a fear, a grave one :-) – Franky Diaz-Trepat Jun 08 '15 at 11:48
  • Another thing that I tried was "simplifying" the request, for example I don't use custom headers anymore (I used to send a header X-Authtoken with an authorization token) now I just use the standard Authorization because I read on the html5rocks.com and MDN about simple vs complex request. Nothing works so far. I'm dying to test this in production to see the outcome on the real server itself and see if there it also preflights. – Franky Diaz-Trepat Jun 08 '15 at 11:53
  • Can you post your network trace from Chrome or Fiddler? – Jeffrey A. Gochin Jun 08 '15 at 13:14
  • Let me see about that. By the way BAD NEWS on the actual server with domain app.domain.co api.domain.co is generating preflight OPTION calls. From the same server. – Franky Diaz-Trepat Jun 10 '15 at 21:59
  • So let me clarify something. It is the XHR call in the browser that generates the OPTION request, not the server. It is what is known as a pre-flight. These comments are getting long. Maybe we should move this conversation to a chatroom? – Jeffrey A. Gochin Jun 10 '15 at 22:46
  • Sure, but didn't you see my post and comments. I know is the XHR but it is making the pre-flights (as I stated) according to a criteria which says a domain is calling another domain. This is the same domain AFAIK and it is still doing that. – Franky Diaz-Trepat Jun 10 '15 at 23:48
  • Actually did see that when I looked back at the post; about that. From my experience it is the server that sets the rule and to what matches as an allowed domain. Using the term domain could be misleading however. There server is supposed to look at the `origin` header, which contains the protocol and the port, and determine if the Origin is a trusted "domain." So it is not just looking at api.mydomain.com, it is looking at `http: //api.mydomain.com`. – Jeffrey A. Gochin Jun 11 '15 at 01:01
  • 1
    This is getting long, but I appreciated so much I am compelled to continue :-) – Franky Diaz-Trepat Jun 11 '15 at 15:16
  • 1
    This is getting long, but I appreciated so much I am compelled to continue :-) All my calls work perfectly fine. My server has the appropriate CORS support and even the pre-flight OPTIONS request support. I get all the responses fine. I am suggesting, that evaluating app.mydomain.com and api.mydomain.com as being cross domains that need this security measure might be wrong, and due to something I might be able to change. Again all the calls work and go to the server and back with payload. But this shouldn't be CORS IMHO (app.mydomain.com ==> api.mydomain.com != Cross Domain Security Needed) – Franky Diaz-Trepat Jun 11 '15 at 15:23