subomains & CORS

Hi Freddy,

Hosting Universal and Indicium on different domains will likely cause CORS issues, so we don’t recommend that setup. If possible, move Indicium behind the same origin (e.g. erp.app.ltd/indicium via a reverse proxy). That way you avoid CORS entirely.

But that will then move thé issues to my.app.ltd right? So the question remains. How can you make this setup work? So both entries work?

If you want to use Indicium from both domains, the recommended approach is to place a reverse proxy in front of Indicium and configure it to listen on both domain names.

This way, both erp.app.ltd/indicium and my.app.ltd/indicium can route to the same Indicium instance, while the Universal GUI can stay on a single origin and avoid CORS issues altogether.

 Is this supported by indicium? To have 1 instance with 2 base url?

Or how would the settings look like in a situation where my.app.ltd which has moble-first custom gui .. with in indicium on my.app.ltd/indicium and Universal GUI on my.app.ltd/erp/ .. the documentation is not very clear on these type of setups. 

To add a bit more detail to the reverse-proxy approach mentioned earlier: the important part is that Indicium itself is still accessed via a single, consistent internal URL.

The reverse proxy simply exposes that same Indicium instance on multiple external hostnames, for example:

• erp.app.ltd/indicium → proxy → http://indicium-internal/indicium

• my.app.ltd/indicium → proxy → http://indicium-internal/indicium

From Indicium’s perspective nothing changes — it doesn’t need to be configured with multiple base URLs. The proxy handles the different domains, allowing both the Universal GUI and the custom mobile GUI to stay same-origin with Indicium and avoid CORS issues.

Well I have that setup, and in development with local accounts that works sofar. On the instance with OIDC (entra) I encountered a lot of issues with correlation issues that it couldn't find cookies. I"m not sure what caused it, but it seems to work now. 

And an additional question why the authorization cookie is limited to the indicium path? And not / of the site? So it protects all assets in a deployment like custom component under for example /app .. I guess this could be an option when the deferred login to indicium is finalized right? 

Hi Freddy,

To comment on your last question: the reason it’s limited to the /indicium path is by design, because that cookie is only meant to secure Indicium itself. Keeping it scoped this way avoids it being sent to other parts of the site that don’t need it, which is safer and helps prevent unexpected side effects.

Because of that, it’s not meant to automatically protect things like a custom app under /app. If /app needs protection, that should be handled separately, for example via the same login mechanism at the proxy or application level.

Deferred login doesn’t really change this concept. Widening the cookie scope to / would be a deliberate design choice with trade-offs, not something that comes for free later.

Can you explain me how you would see this? What other options you see? 

This might go a bit too much into detail for the Community. Could you please reach out to your Technical Account Manager? They will be able to look into this further and help provide the right answer for your situation.