CORS Issue - fixed - but maybe it needs more attention?

Site Operators
1

I discussed this shortly on Slack, but it may need more attention. I don’t want to bury a potential issue for future operators on Slack.

When trying to create or modify a course, I was faced with CORS issues, it came from me accessing the CMS with https://apps.openedx.mydomain.com/authoring/home url instead of https://studio.openedx.mydomain.com/. The second one redirect to the first and set a cookie it seems.

The natural thing to do, is to put the first URL in favorite on the browser. And later when skipping the studio subdomain, I am not faced with a login screen on the studio url (authoring/home) but everything is displayed as if I am correctly connected, I can for example see every course, but others actions will fail an show a CORS error in the console.

So the fix is to always visit and put in favorite https://studio.openedx.mydomain.com/ instead of https://apps.openedx.mydomain.com/authoring/home. And additionally removing all cookies once (for chrome: chrome://settings/content/all?search=cookie).

Any opinion on that?

2

I’m not sure who to tag in this one. Maybe @Tim_McCormack or @feanil ?

3

Not my area of expertise. It does sound like a pretty annoying bug. Maybe course authoring MFE or studio is making some overly limiting assumptions about the domain structure of deployments.

4

@AmbroiseRabier if you hit them in the wrong order, what URLs fail with CORS errors? And what are the HTTP verbs involved?

CORS issue suggest that the authoring UI is trying to hit the studio backend APIs and the backend is rejecting the calls. The fix is probably to update the studio settings to allow requests from the apps subdomain if it isn’t already doing that but it may be that there are requests being made that should be made differently also so more information would be useful.

5

I mostly tried with creating a course. Also on the course creation form, the existing organizations are loaded in the organization input. When URLs are hit in wrong order, the existing organizations won’t be loaded and the suggestions stays blank.
I would bet that all update/create/delete operation would be faced with CORS, and being able to connect through on the CMS and view the list of courses is probably the exception.

The preflight OPTIONS request returns 200 but does not include the required CORS headers (Access-Control-Allow-Origin), so the browser blocks the request.

Request URL
https://<OPENEDX_DOMAIN>/oauth2/authorize?client_id=cms-sso&redirect_uri=https%3A%2F%2F<STUDIO_DOMAIN>%2Fcomplete%2Fedx-oauth2%2F%3Fredirect_state%3D<STATE>&state=<STATE>&response_type=code&scope=user_id+profile+email

Request Method
OPTIONS
Status Code
200 OK
Remote Address
<IP_ADDRESS>:443
Referrer Policy
strict-origin-when-cross-origin
alt-svc

------ RESPONSE HEADERS
h3=":443"; ma=2592000
content-length
0
content-type
text/html; charset=utf-8
date
Tue, 17 Mar 2026 12:44:28 GMT
server
Caddy
vary
origin, Cookie

------ REQUEST HEADERS
:authority
<OPENEDX_DOMAIN>
:method
OPTIONS
:path
/oauth2/authorize?client_id=cms-sso&redirect_uri=https%3A%2F%2F<STUDIO_DOMAIN>%2Fcomplete%2Fedx-oauth2%2F%3Fredirect_state%3D<STATE>&state=<STATE>&response_type=code&scope=user_id+profile+email
:scheme
https
accept
*/*
accept-encoding
gzip, deflate, br, zstd
accept-language
fr-FR,fr;q=0.9
access-control-request-headers
use-jwt-cookie,x-csrftoken
access-control-request-method
GET
origin
null
priority
u=1, i
referer
https://apps.<OPENEDX_DOMAIN>/
sec-fetch-dest
empty
sec-fetch-mode
cors
sec-fetch-site
same-site
user-agent
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36