angular OPTIONS http preflight on “Same Domain”?

[Franky Diaz-Trepat]

Hi everyone I'm new to continu and am building a new app in angular and I'm having a CORS headache.

The issue:

HTTP OPTIONS (pre-flights) calls before any type of request. Even if the request is the same like GET ..../users it calls and calls OPTIONS on the server.

The circumstances/environment:

This happens on two fronts: 

1) Explained also here (http://stackoverflow.com/questions/30656293/angular-options-http-preflight-on-same-domain) is that mimicking a local.domain.co in my local environment with self signed certificates I get pre-flight OPTIONS calls for api.domain.co

2) The real grave one is that on production my app served from app.domain.co pre-flights OPTIONS calls/requests to api.domain.co.

In both cases EVERYTHING  is working fine, server has the support for CORS and all the requests get answered.

The plea:

Oh my Gosh, please please help me, I don't know what to do :-) :-) :-)

The wished outcome:

I want to get rid of the pre-flight OPTIONS calls or at the very least cache it so the same call doesn't create another pre-flight OPTIONS call over and over again.

Last question

Could it actually be that api.continu.co and app.continu.co are evaluated as being Crosss Domain?

What is the proper structure to handle this, I haven't notice this happening on google apis and things like that.

Thank you so so much in advance

[Sander Elias]

Hi,

It is possible to cache preflight requests. You need to set an header (on your server). iirc the header is Access-Control-Max-Age

Regards
Sander

​

[Franky Diaz-Trepat]

Hi Sander, thanks for that, I'll add that right away.

I would still love to remove pre-flight all together.

Thank you so much again,

Franky

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/8krFnmC_Svs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Franky Diaz-Trepat]

Actually It didn’t worked.

• Access-Control-Allow-Credentials:true

• Access-Control-Allow-Headers:Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Credentials….. many more

• Access-Control-Allow-Methods:*

• Access-Control-Allow-Origin:https://local.continu.co

• Access-Control-Expose-Headers:api-version, content-length, content-md5, content-type, date, request-id, response-time

• Access-Control-Max-Age:1800

• Connection:keep-alive

• Date:Thu, 11 Jun 2015 17:59:41 GMT

• Request-Id:a245fa90-1063-11e5-908a-fd4c0038851a

• Response-Time:1

• Server:nginx/1.1.19

It still does not cache pre-flights OPTIONS 

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Sander Elias]

Hi Franky,

I just went to the source. In order to make this work, you have to all that in account. Often this stuff does work just a bit different in every browser, so you need to do some testing around to get it right. And then there are some times that browsers just plain ignore standards. Sadly enough, that's the reality we have to live with.

Regards

Sander

[Sander Elias]

Hi Franky,

Here is an relevant SO question. It doesn't look to bright tough!

Regards

Sander

[Franky Diaz-Trepat]

Thank for all these great topics, but this is STUPID.

pre-flights are supposed to address security in CROSS ORIGIN RESOURCE SHARING

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated.^[1]

I don’t understand how app.mydomain.com and api.mydomain.com  

1-A restricted resource

2- ANOTHER DOMAIN 

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Sander Elias]

Hi Franky,

I tend to agree with you. But I did read most of the stuff I linked to you, and there is an explanation about the sub-domains. In a larger organization white-listing all sub-domains will be harmful. And if that is in the spec, it would be an too easy mistake. I don't like it, but I do agree with W3C here. 

This means that everything that's not on your primary domain (the page that boots the app) needs to go trough CORS.

I think the CORS caching mechanism should be less rigid in what it accepts. Filing an issue on that by W3C will help. Although you need to be very persistent to get it in there, and it will take years before it will be implemented somewhere!

Regards

Sander

[John Maxwell]

On 06/11/2015 09:30:28 PM, Franky Diaz-Trepat wrote:
> I don’t understand how app.mydomain.com <http://app.mydomain.com/>
> and api.mydomain.com <http://api.mydomain.com/>

>
> 1-A restricted resource
> 2- ANOTHER DOMAIN

Can't help with most of your questions, but I'd like to point out that
"app.mydomain.com" and "api.mydomain.com" are indeed separate domains.
The fact that they're both sub-domains of the domain "mydomain.com"
doesn't change that. So there's that much of your problem.

-John

--
John Maxwell KB3VLL jm...@jmaxhome.com

For those who like this sort of thing, this is the sort of thing they
like.

[Franky Diaz-Trepat]

I don’t think so. They are subordinates of the same domain.

Domain names are organized in subordinate levels (subdomains) of the DNS root domain, which is nameless.

Then com. then mydomain then subordinates to mydomain like app api app2 these are all subordinates within my organization.

Never mind that now. The concept of CORS is heavily pointed towards having one site like app.domain.co ask RESTRICTED resources from another domain like js.yahoo.com.

The fact that only Chrome and Firefox, and in Firefox you can whitelist sub-domains might also be something worth noting in this discussion.

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Franky Diaz-Trepat]

Just to add to the context. Right now our stack is a MEAN stack

{mongo}

{express/restify} <—api

{express} <— web-app (with all of the api duplicated route definitions)

{angular} <— web-app

Now i’m working on doing this:

[mongo]

[restify] <— api

[angular] <— webapp

Our api hasn’t change it is still api.mydomain.co

Our current apps that don’t do any preflights because they call the expressjs server that served them, then the expressjs server calls the api, gets the results, and sends back the results to angular. That can be done and it will remove the pre-flight at the cost of having duplicated http calls (GET /users => web-server => GET /users => api).

Where is the security concerns? the brilliant implementations and definition of what CORS call should be?

There is no way to avoid duplicating http calls? opening sockets and all that?

I either have duplicate call on the server that served the angular-app or in the browser (on a smaller scale because there is no payload) with the OPTIONS and GET/POST/DEL calls.

This is silly. 

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Franky Diaz-Trepat]

Even more on the subject and related to the posts and information kindly given by Sander Elias.

it is impossible to avoid a preflight on PUT/DELETE requests

If your API returns JSON, note that a Content-Type of 'application/json' also triggers a preflight.

And the author ends by saying:

There's very little you can do to limit preflights over the course of a long running app. I'm hopeful the authors of the CORS spec will try to address this in the future.

So all these points make no sense because the only thing that matters is that the content type will always be application/json.

This is so frustrating. How does all other api work? like google maps and stuff like that? I bet they get away with no pre-flight :-)

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Sander Elias]

Hi Franky,

Yes, Rest and cors are not best friends. There are some ways to get around the prefight.

1. server everything from the same (sub)domain. The exact same one. and yes, www.domain.com is another subdomain as app.domain.com. They are in the same domain indeed, but are indeed different subdomains, So cors will kick in, nothing you can do about that.

2. serve everything via winsockets. no preflights anymore.

3. switch over to http2. still preflights but those don't have the same performance hit.  This is also stupid, because the connection stays up, so the prefight don't serve any purpose anymore.... this might get addressed sooner then the normal preflight situation tough.

Regards

Sander

[John Maxwell]

On 06/12/2015 05:42:52 AM, Franky Diaz-Trepat wrote:
> I don’t think so. They are subordinates of the same domain.
>

Yes. They are *also* separate domains. There is no difference between a
domain and a subdomain for this purpose; the distinction is purely a
commercial one. CORS doesn't recognize the distinction you're trying to
make.

-John

--
John Maxwell KB3VLL jm...@jmaxhome.com

Nihilism is best done by professionals.
-Iggy Pop

[Franky Diaz-Trepat]

Ok man, it sucks anyways :-)

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Franky Diaz-Trepat]

I wonder if I use atom or XML would it still be considerer as a CORS operation. Because of this quote from the post linked by Sander

it is impossible to avoid a preflight on PUT/DELETE requests

If your API returns JSON, note that a Content-Type of 'application/json' also triggers a preflight.

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Franky Diaz-Trepat]

By the way on this topic. Something it didn’t occurred to me before is that if a CERTIFICATE is good for *.domain.com so it should be CORS.

subject: serialNumber=y4nrR8mx9wielToDHh7GN7SFjXsl7uAW; OU=GT23349928; OU=See www.rapidssl.com/resources/cps (c)14; OU=Domain Control Validated - RapidSSL(R); CN=*.domain.co

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Sander Elias]

Hi Franky,

Only if you put out for an wildcard certificate, that is especially build to span all sub-domains. Standard certificates only work on a single (sub) domain.

Regards

Sander

[Franky Diaz-Trepat]

By the way on this topic. Something it didn’t occurred to me before is that if a CERTIFICATE is good for *.domain.com so it should be CORS.

subject: serialNumber=y4nrR8mx9wielToDHh7GN7SFjXsl7uAW; OU=GT23349928; OU=See www.rapidssl.com/resources/cps (c)14; OU=Domain Control Validated - RapidSSL(R); CN=*.domain.co

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co

[Franky Diaz-Trepat]

My company has that certificate on production environments, I didn’t know that. Thanks Sander.

Franky Diaz-Trepat
Full Stack Engineer
+1 (720) 295-0592 / 401-1276
skype: franky.diaz.trepat
fra...@continu.co