People are asked to sign in again inside the frame
The embedded app appears but never stays signed in, or bounces back to the sign-in page on every reload. The embedding setting is not the cause — this is the browser refusing to keep a session for a page inside another site.
Allowed websites decides who may hold the page, and nothing else. Once the app is on screen, staying signed in depends on the browser being willing to keep a session for a page that belongs to a different site from the one around it, and some browsers will not.
The browser is blocking the session inside a frame
Most commonA page inside another site’s page is treated as third-party, and a browser set to block third-party cookies — or one that blocks them by default, as Safari does — drops the session as fast as Offision creates it. The symptom is a sign-in that appears to succeed and a reload that lands back on the sign-in page.
It is a browser decision, not something Offision can override. Confirm it by opening the same portal page in a browser with third-party cookies allowed; if the session holds there, this is the cause. Then choose one:
- Serve the portal page and Offision from the same site, so nothing is third-party. This is the only fix that works in every browser.
- Have the portal open Offision in its own tab instead of framing it.
- Ask people to allow cookies for the Offision address in their browser — a per-person setting, so it does not scale past a small team.
The portal page is served over plain http
CommonA session for an embedded page can only be kept over https. A portal page
served over http on a public address will not hold one, and the address is
refused by Allowed websites anyway unless it is on your own network.
Put the portal page on https and correct its address in Allowed websites
to match.