A Micro-App is a standalone web application embedded into the Allthings interface.
This is the simplest form of integration into the Allthings platform and only requires a minimal amount of effort to ensure compatibility.
A Micro-App that needs to connect to user data or other data on the Allthings platform has to be authorized via OAuth 2.0 and can therefore access and modify resources on the Allthings platform on behalf of the user.
Cookies in 3rd-party Micro-Apps are by default NOT supported. The way to keep a session must be purely via the OAuth flow (basically using the OAuth access token as session token).
In the case of integrating existing apps that cannot get rid of session cookies (e.g. shops), there’s one solution: Running the MicroApp in a subdomain of the app domain (or on the same Top-Level-Domain).
This is however not a scalable solution, as it involves manual adoptions (setting up CNAME DNS entries and SSL certificates).
The reason Cookies are not supported is that Apple’s Safari rejects 3rd-party cookies by default, no matter if they’re set in an iframe or via XHR request. Safari will accept cookies from domains that have been visited before, but that would only work if the Micro-App is opened in the top level frame.
Since MicroApps are displayed in an IFrame, the Allthings app domains need to be allowed:
Content-Security-Policy: frame-ancestors *.allthings.me *.allthings.app;
To prevent Clickjacking in Internet Explorer - which does not support the
frame-ancestors policy - the
header must be used, which unfortunately only supports a single non-wildcard
domain as framing exception.
To still support multiple (wildcard-) domain exceptions, the current app domain can be appended to the iFrame URL, e.g.:
The framed MicroApp (
example.com in this example) can then compare the
frame-ancestor parameter (the URL-encoded
with a predefined whitelist and if valid, set the appropriate
X-Frame-Options: ALLOW-FROM https://example.allthings.app