App iframe, cookies and 3rd party contexts

Understanding how Apps work within a 3rd party context in Duda.

2024 Privacy Sandbox Update

In 2024, Google Chrome is starting its deprecation of 3rd party cookies. As of this writing, it's currently enabled for 1% of Chrome users globally and in 2024 will be enabled by all Chrome users sometime in late 2024. Google maintains an updated timeline on their privacy sandbox website.

This directly impacts how Duda Apps authenticate users into the App Iframe, within the Duda product. When Chrome enables moves to no longer support 3rd party cookies, users will fail to authenticate into your App unless you make some small cookie changes.

The core of this change is that you need to set the Partitioned flag on the cookie you send down to the user. We've updated our SSO reference to reflect this and give more details.


When Duda Opens your App inside of the Duda Editor, we do so in an iframe with additional SSO URL parameters sent, so you can authenticate that the user is from Duda. This means that your App URL loads as a 3rd party domain and any browser restrictions that are placed on 3rd party websites/hosts will apply to the front end of your App.

We open your App in an iframe so users do not have to leave the context of the Duda editor to leverage your App. This provides the best user experience.

Example of an App Open, in an iframe, within the Duda editor.

Example of an App Open, in an iframe, within the Duda editor.

The largest impact this causes is setting authentication (or other cookies) from within the iframe. Browsers will block cookies that your App tries to set because your setting them from a 3rd party cookie context.

App <> Duda Editor Communication

Duda provides a simple set of Javascript APIs that enables you to communicate with the parent editor. The way this works is by using window post messaging to send a command from your App into the Duda editor. These allow you to prompt users for an upgrade, refresh the site editor in the background, and more.