Can I only use one domain?

There are times when you need to use multiple domains.
In the past, there seemed to be an IDENTITY__MULTIPLEDOMAINS env,
but it appears to have been removed.

identity-server/.well-known/openid-configuration
Since there is only one URL_BASE input, the issuer is fixed, so only one domain can log in.

Is there a way to use Squidex across multiple domains?
For example, a company-provided OAuth2-based SSO has a policy that restricts the redirect_url to only the company domain.

How would you solve it then? You need to host Squidex under a subfolder or subdomain. Multiple domains would not really help afaik.

RedirectToAuthorizationEndpoint

I tried a trick to force the redirect_uri to change in the function, but it seems to be blocked by cookie policy.

I couldn’t find a solution.

I am not sure what you mean. Sorry.

squidex server operation integrates the backend and frontend into a single server. It appears that the server can be operated as a single unit, but the admin spa server cannot be operated separately.

If you’re running it as a service, exposing the admin page can be a bit burdensome.
Furthermore, there seems to be no alternative for scenarios where you want to use separate domains for the internal admin SPA and externally exposed API domains.

Is there a history that must be run as one?

I have never run it separately, nor do I know anybody who has done it. There is also no frontend server, just a few files for the SPA.

I see. I was thinking about simply disabling frontend execution on the server used for service exposure and accessing it as an admin user from another server.

Server A has an admin page
Server B has the admin page disabled

If a post is updated (or some other action is taken) on the A admin page, will there be any issues with server B’s memory caching, etc.

since they’re all accessing the same MongoDB and event store?
both servers A and B will likely use different BASE_URL domains.

You can provide a PR, but I do not see the priority at the moment.

@Sebastian
Are there any expected issues if I skip the first line of the UseFrontend and AddSquidexFrontend functions with “disable”?

In my actual testing, I was able to use the API as intended, so I didn’t find any major issues.

for externally exposed services, I’m disabling the UI and using it exclusively for the API (on a separate domain).

For admin use (on the company network), I’m planning to run it on a separate server.

Of course, both are connected to servers like EventStore and MongoDB.

I wanted to separate the frontend SPA and run a Node.js server, but it’s tightly coupled with IdentityServer, making it practically impossible.

At this point, the disable option seems like a compromise.

public static void AddSquidexFrontend(this IServiceCollection services, IConfiguration config)
{
    var uiOptions = config.GetSection("ui").Get<MyUIOptions>();
    if (uiOptions is { Disable: true })
    {
        return;
    }

    ...
}

The identity server does not care on which domain the frontend runs. It is technically a separate app anyway.

yes, but doesn’t the login screen request the identity server API? If you’re running a Node.js server, you’ll need to configure a separate identity server. This actually increases complexity.
If there are no major issues with the above disable method, I will do more actual testing and provide a PR. What potential issues might there be?

If it is only the code above or reasonable complexity a PR is fine.