Do you have any instruction on how to specify a different CORS domain per CN organization? We are looking to have

dev/staging/production

organizations, and specify different CORS domain for each.

Hello, this setup is not currently possible. We already have an internal feature request to resolve this issue.

Related to this, I am planning to setup a proxy to resolve CORS problems. Deploying it as a Lambda Function on AWS, the API Gateway has a 30 seconds timeout on requests. Can we expect it that the GD.CN REST endpoints would return within this 30 second limit? If no, what should be the expected max response time? Thanks

@Vajk Hermecz the upper hard limit is actually defined by ingress controller, and it is involved by various timeout settings (proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout). At the worst-case scenario, some response should usually be returned within 125s limit. It's a interesting idea to put a cors-proxy in front of GDCN, but be prepared that you will most probably face issues with redirects from /appLogin if you plan to use the a single GDCN deployment (with multiple organizations) as a backend for multiple UI apps hosted on multiple domains. As I wrote above - it is currently very limited and it needs to be resolved on backend side.

UI would use bearer tokens to connect though javascript, that way, if my calculations are correct, we avoid the /appLogin redirections. One goal with the proxy is to solve CORS, the other goal is the AUTH. If we assign a separate ApiToken for each workspace (using the workspaceId as the tokenId), we can easily implement a per-workspace authorization as well. Might be useful to mention this 125sec somewhere in the Api Docs. So this 125sec, is this a theoretical max, or do you have a lower 99% response time? (Trying to figure out what should the proxy support to not to hurt the QoS of GD.CN platform.) Thanks

I see, so your proxy will inject bearer token based on workspace specified in path; it's clever. Keep in mind the token is authN, you can use the same token for accessing all WS within a given organization where the user with token exists, until we finish permission management system. Those 125s is also rough estimate and depends to actual setup of ingress controller. 99th percentile of the response time varies on a wide variety of aspects - what API endpoint, cluster resources and utilization, database performance, and so on. Some API endpoints (like /api/layout/...) also depend on the number of workspaces and model complexity. Long story short, these values should be measured empirically for particular installation. I can provide you with our values (taken from our development and testing cluster using Prometheus metric

nginx_ingress_controller_response_duration_seconds_bucket{path=~"/api.*"}

):

le [sec]	requests [1]	perc [%]
0.005	1619	0.35%
0.01	1714	0.37%
0.025	41606	9.07%
0.05	210452	45.90%
0.1	280063	61.08%
0.25	375183	81.83%
0.5	422069	92.06%
1	443476	96.73%
2.5	452762	98.75%
5	455484	99.35%
10	456387	99.54%
∞	458484	100.00%

So only <0.5% requests took longer than 10s. I hope it helps.