The shared iFrame using our cloud URLs requires cookies and scripts to operate a interactive model viewer though which users collaborate on the rendered design. As such those, cookies and/or scripts will be [tried to be] established with our ADSK‘S website’s context and this suggests cross-origin matter - basic internet behavior kicks in. Many browsers block this by default for last several years to ensure user privacy where cookies or scripts can go outside their iframe and read host data info - such is the nature of malware. Meaning, these cookies will run outside the context of your hosted website where you wish to embed to, hence from your hosted page’s point of view, Chrome sees our iframe’s cookies as external 3rd party and engages. This is a light non-technical approximation of what might be happening under the covers based on the symptoms.
Specifically setting autodesk’s base url website in the exclusion rule from 3rd party blocking suggests your host page to trust the cookies and scripts we bring with the iframe. Unblocking all carte blanche like you did is definitely not recommended as I explained other things the site embeds or interacts with may not be well-intended as our viewer to stay within its cone..
Is it possible that you might be embedding other iframes that either bring cookies that are non-essential and they do get blocked yet those iframes run, or they do not require cookies and/or scripts whatsoever. Another possibility is those other vendor sites and your host site support what is called CORS where each can allow-list domains/ip addresses etc telling scripts to run from respective external domains and things would work. Not sure what setup you have as this might be your IT matter. Nevertheless, Cross-Origin Resource Sharing is not available in Fusion currently.
Martin Gasevski | Fusion 360 Team Product Manager
Fusion
