Iframe Embedding
The console frames its sibling apps (Mail, SMS, SEO, …) inside iframes so they appear as one product. Two things make this work: a platform-wide Content-Security-Policy that permits the framing, and the SSO hand-off that silently authenticates the framed user.
The global CSP
A single Content-Security-Policy is applied platform-wide (not per site). It sets:
| Directive | Value | Effect |
|---|---|---|
frame-src |
includes https://*.inklura.fr and https://auth.1clic.pro |
The console may frame its siblings (and the IdP) |
frame-ancestors |
https://*.inklura.fr |
Each app may be framed by a *.inklura.fr parent |
So frame-src governs what the console can embed, and frame-ancestors governs who is
allowed to embed a given app — both scoped to the *.inklura.fr family plus the IdP.
Per-site CSP is not honored for auto-vhost sites. The global policy is authoritative —
a Content-Security-Policy header you set on your own PRISM app is not what governs framing.
Any *.inklura.fr subdomain is already covered by the global policy. Standing up a new
inklura subdomain needs no CSP change to be frameable by the console.
Embedding a sibling app
Don't point the iframe at the app's page directly — point it at the console's SSO hand-off, so the framed app authenticates silently before it renders:
<iframe src="/api/manage/designer-sso?app=mail&next=/inbox&embed=1"></iframe>
The designer-sso route mints the short-lived hand-off token, 302-redirects into the sibling
on the same registrable domain, and the app's landing route mints its local session and lands
on next. See Single Sign-On for the token, TTL, and audience checks.
Same-site vs new-tab
Not every sibling is embedded. When the console launches an app:
- Same-site apps (same registrable domain) are embedded in the iframe — the CSP above permits it.
- Cross-site apps are launched in a new tab instead of framed.
See also
- Single Sign-On — the hand-off token that authenticates the framed user
- Provisioning Subdomains — standing up a new
*.inklura.frapp