Skip to main content

Current Limitations

  • Session length - At the moment, using a valid embed url will create an embed session that lasts 24 hours. That embed session will be unusable after 24 hours. Visiting a new, valid embed sso url at any time will create a new session.

  • Incognito Chrome - Incognito chrome requires allowing 3rd-party cookies. These can be found under Chrome > Settings... > Privacy and Security > Third-party cookies. Then set the option to Allow third-party cookies.

  • Copy Value - iframes, by default, restrict access to the "clipboard" of the viewing device. When you click on a data value within Omni and select Copy value, the value will not be copied to your clipboard. In order to allow copying data values from an Embedded Omni iframe, you will need to add allow="clipboard-write" to your iframe declaration. For example:

    <iframe src={omni-embed-url} allow="clipboard-write" />

    If you want stricter permissions, you can modify the allow clause to include the specific domain you want to permiss "clipboard-write" access for. For example:

    <iframe src={omni-embed-url} allow="clipboard-write self https://acme.embed-omniapp.co/" />

Safari, Mobile Safari and Mobile iOS Chrome Support​

Omni currently uses cookies to manage it's authentication sessions. When embedded in iframes, browsers like Safari view these as third-party cookies. By default, Safari takes a privacy-minded stance on these cookies and blocks them, effectively blocking access to Omni content.

There are a few options to allowing authorization in Safari, each with their own pros and cons:

  1. Use the Safari default behavior, requiring a multi-step handshake to allow 3rd party cookies.
  2. Use a special vanity domain to allow cookies from Omni to originate from the embedding domain.

1. Default Safari Behavior​

Pros & Cons

  • Pro: Requires no setup or changes for end user
  • Pro: Retains Safari's default cookie behavior and anti-tracking philosophy
  • Con: Extra steps to authorize cookies, then login

Safari provides a complicated meet-and-greet handshake to enable third-party cookies in supported contexts. This requires explicit action by the user. The steps are:

  1. Attempt to load the Omni dashboard. If cookies are not permitted display, a button that, when clicked, will send the user directly to the Omni instance being embedded.
  2. Once the embedded Omni instance has been visited in a non-embedded context, send the user back to the embedded context.
  3. Present the form again which will now prompt the user to allow access to "use cookies and website data". Clicking "Allow" will then redirect again, and display the embedded dashboard.

This process should only be required the first time a user accesses embedded content in Safari. Occasionally Safari may ask the user to authorize access again, displaying the form the user must click on.

The steps look like the following:

Step 1 - Visit Embed URL, Click "Allow Access"

Step 2 - Visit embedded site directly, click "Back to access page"

Step 3 - Just as in step 1, Click "Allow Access"

Click "Allow"

And you're in!

2. Vanity Domains​

Pros & Cons

  • Pro: Eliminates the multi-step Safari auth flow
  • Pro: Retains Safari's default privacy setup
  • Con: Requires infrastructure setup

Note: Vanity domains elminate Safari's multi-step auth flow only if Omni is embedded in the same parent domain as the vanity domain (eg: omni.myapp.co is embedded in myapp.co).

See instructions here for setting up a vanity domain.