Does appwrite sent the correct Access-Control headers when authed with API key?

I'm trying to use external Auth with appwrite by proxying client side requests with custom API endpoints that verify tokens and the make the request on behalf of the client with API keys as explained here https://discord.com/channels/564160730845151244/1121753945593872455/1122409631034122270

I'm worried about something though. While I can read permission on resources before sending them to the client or returning 401 Unauthorized error, appwrite provides no way to read app info from the server even when authed with API key. I want to know if I can still rely on appwrite to send the correct Access-Control-Allow-Origin headers to be forwarded to the client/browser on this case. Or I should request that the users define the origins again (maybe with env variables) on the server and handle that myself.

Hope it's understandable.

Btw, I do know I'll have to make sure the Origin header is set on the request object for this to work.

I'll like to maintain the CORS rules enforced by Appwrite

Hey 👋 CORS protect a hostname (domain). If your proxy is on different domain than Appwrite API, you would need to protect your proxy as well.

If you simply proxy Appwrite's response headers and your proxy lives on another domain, browser will (should) complain about CORS.

Make sense?

I don't really get you

Does that mean that appwrite still sends appropriate Access-Control-Allow-Origin header when authed via API key?

Anyway, I think this is what I should be doing; Since the proxy is meant to shield the client from direct access to the Appwrite API, the access control headers returned by Appwrite should not determine the access control headers I'll send to the client. I have to specify what access control headers I want to send to the client since the proxy's URL is what the client requests, not the Appwrite API URL. Do you think that makes sense?