Api: Same-Origin Errors with 3d model assets
This has been an ongoing issue I've had to deal with, but my gear viewer seems to get hit by random same-origin policy errors when loading 3d assets directly from bungie.net. I'm not certain, but I think it might be related to making API calls client side and/or when I bounce between my development environment and the production environment. On that note, better documentation on how to set the origin property of an application would be helpful as there's a like 20 min delay to confirm whether you've put in the correct details and I've just left it set to "*" for most of my apps.
lowlines
All 18 comments
Can you use a tool like Fiddler (or just use Fiddler) to grab some logs of this happening. I can diagnose from there.
In general, the Cross Origin Resource Share (CORS) is a rule enforced by your web browser, not by Bungie.net. The browser uses hints from the website to decide what to do. For all /platform URL calls, Bungie.net tells the browser to be as permissive as possible, and then Bungie.net turns around and enforces the origin based on API-Key + Application config. The application config is usually as simple as "whatever your browser is putting in your Origin header, put that in your Application config."
Things get complex outside of the /platform path. For example, Gear items are cached by Cloudflare, and the origin policy response headers the browser uses to decide if the request is permitted get cached along with them. We have had bugs in the past where the behavior varies depending on exactly what ended up in CloudFlare's cache.
As always, these things are hard to figure out with out detailed traces. If you can provide something, it would be greatly appreciated.
Tetron-bng
on 22 Oct 2017
Fiddler would be tricky as it would require exposing an API key and I'm also not sure it would replicate the same conditions as it is probably a browser issue, notably on Chrome (though I haven't tested other browsers much). I'll see what logging information I can gather next time I look into it.
If it helps, my dev environment domain is lowlidev.io while my website is lowlidev.com.au and it seems to lock the origin header onto one and blocks the other one until I clear my cache.
lowlines
on 23 Oct 2017
This rings a bell. Let's say you are testing and your browser bounces off of lowlidev.io to grab a gear item at url https://www.bungie.net/foo. Your browser caches that, including the response headers that permit lowlidev.io to work on your browser. Later, you test against lowlidev.com.au and your browser goes to https://www.bungie.net/foo and gets the locally cached response. It thinks, "Hey, this only permits requests from lolidev.io to interact here, so it blocks the request. Clearing the cache makes sure that you get a fresh response from https://www.bungie.net/foo and everything works again for a while.
I have seen other apps work around this problem by adding a query string parameter that makes the URLs different so the responses are cached independently. For example, lowlidev.io might use https://www.bungie.net/foo?cachebuster=lowlidev.io and your other site would use https://www.bungie.net/foo?cachebuster=lowlidev.com.au.
Does that make sense?
Tetron-bng
on 23 Oct 2017
Is Bungie including ‘Origin’ in the Vary headers returned for cached responses that include an Origin header? If not, that may explain some things.
On Oct 22, 2017, at 18:48, Paul Tidwell notifications@github.com wrote:
This rings a bell. Let's say you are testing and your browser bounces off of lowlidev.io to grab a gear item at url https://www.bungie.net/foo. Your browser caches that, including the response headers that permit lowlidev.io to work on your browser. Later, you test against lowlidev.com.au and your browser goes to https://www.bungie.net/foo and gets the locally cached response. It thinks, "Hey, this only permits requests from lolidev.io to interact here, so it blocks the request. Clearing the cache makes sure that you get a fresh response from https://www.bungie.net/foo and everything works again for a while.
I have seen other apps work around this problem by adding a query string parameter that makes the URLs different so the responses are cached independently. For example, lowlidev.io might use https://www.bungie.net/foo?cachebuster=lowlidev.io and your other site would use https://www.bungie.net/foo?cachebuster=lowlidev.com.au.
Does that make sense?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
floatingatoll
on 23 Oct 2017
Yes, that is likely the major problem. I admit, I have been stumped with the MVC/IIS stack we use. The vary header is not easy to manipulate.
Tetron-bng
on 23 Oct 2017
Ah I do something along those lines with my css/js files to bypass the obsessive caching modern browsers seem to do these days! If it thinks the assets are different files, then that should sort it out.
It would defs be good to add more detail/documentation about the Origin header field on the App settings page, ie how it works, example values, etc.
lowlines
on 23 Oct 2017
Yep, appending a new ?{Date().getTime()} to assets urls for my dev environment fixed the origin conflict. 👍
lowlines
on 23 Oct 2017
Oh geez, I can’t believe it was that easy. I’ve been working on a renderer as well and this just answered some questions. Thanks!
ckhicks
on 23 Oct 2017
@lowlines Appending the date will completely break the cache, which means you download the gear every time you need it which will be a performance hit for your application. If you append the origin you only break it enough to avoid the origin issue.
Tetron-bng
on 23 Oct 2017
@floatingatoll I remembered ensuring Origin is added to the Vary header and that it ended up not working. I did some research this morning and found it does work for /platform endpoints, but is not working for image and probably gear endpoints. Instead IIS overwrites the intended Vary header with Accept-Encoding. There are some work arounds I will explore.
Tetron-bng
on 23 Oct 2017
I wish I had IIS/MVC skills to help you! If you ever need the research, I'm
happy to at least try to come up with something.
Also, you could use Cloudflare to overwrite the header, I think, if you
tire of arguing with IIS about it. I don't specifically encourage that
path, but just to note its presence on your opportunity list.
On Mon, Oct 23, 2017 at 8:50 AM, Paul Tidwell notifications@github.com
wrote:
@floatingatoll https://github.com/floatingatoll I remembered ensuring
Origin is added to the Vary header and that it ended up not working. I did
some research this morning and found it does work for /platform endpoints,
but is not working for image and probably gear endpoints. Instead IIS
overwrites the intended Vary header with Accept-Encoding. There are some
work arounds I will explore.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Bungie-net/api/issues/250#issuecomment-338704667, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFqDA96iWAZE9jg2ZLBKRtJHPVgOMRTks5svLW_gaJpZM4QBzdD
.
floatingatoll
on 23 Oct 2017
@Tetron-bng yep and that is why i'm only applying it in my dev environment where caching is an issue. Once it hits production, it will just use the original urls. Although, I guess if there are multiple apps/websites the user is using, then they might hit a same origin policy error. 🤔
lowlines
on 24 Oct 2017
Yes, possible. I dug into the Vary issue. It seems that it is Cloudflare removing the Vary header. I assume the client adding the Origin header should cause Cloudflare not to cache the response anyway (although that is a shame since it is essentially static). I assume your app is loading these static files via Ajax, correct?
Tetron-bng
on 24 Oct 2017
Yeah ajax. I didn't want the extra overhead of caching/loading from my own server.
lowlines
on 24 Oct 2017
I think what I need here is the ability to return "Access-Control-Allow-Origin: *" for items under the /common/ path. These are static values and should be cached and not really protected as no code runs on the server to return these.
Tetron-bng
on 24 Oct 2017
I would appreciate that as well. I’ve done a bunch of head-desking trying to debug the responses for different content types. I appreciate the need to control those but not wrestling with CORS on /common/ resources would be amaaaaaazing. :D
ckhicks
on 24 Oct 2017
Ok, this is checked in. This should make our planned deployment in two weeks. Geez, can't wait to see what you guys are building.
Tetron-bng
on 24 Oct 2017
This should be resolved now.
Tetron-bng
on 3 Nov 2017
Related issues
gitFurious
·
3Comments
mikewojtkiewicz
·
3Comments
nathabba
·
3Comments
ttgmpsn
·
3Comments
lax20attack
·
4Comments