@U09PU2K1G7J can you guys take this over? My strong suspicion is that there’s a domain mismatch between the allowed_origins and the actual domain on the page, but I’m not positive.
is there any way to check the logs of the requests on my side?
What we have confirmed in production is:
The failing browser origin is https://platform.nexus-solutions-lab.com
The token is being created with allowed_origins that include that exact origin
We also tested with a temporary hardcoded single-origin token using only that exact domain, to eliminate any ambiguity around multiple origins
• Token creation succeeds, but the browser request to the Connect components endpoint still fails with missing Access-Control-Allow-Origin
So at this point, unless there is some additional domain normalization rule on your side that we are missing, it does not appear to be a simple mismatch between the page domain and allowed_origins.
Could you please verify how CORS is being applied on the components endpoint for Connect tokens, especially for browser preflight / GET requests?
Hi , are you calling the /v1/connect/{project_id}/components/{component_slug} endpoint directly from the browser in your frontend application, or are you using the official @pipedream/sdk/browser or @pipedream/connect-react client?
Hi Maycon — we are using the official frontend client flow
Specifically:
• @pipedream/connect-react: 2.7.2
• @pipedream/sdk: 2.3.5
I see. I tested this call through the Demo App and everything is working correctly on our side. Could you share how this request is being made in your frontend code? You can send it to me via DM if you prefer.
Solved
Root cause was that the Connect token was being created with static allowed_origins from backend config instead of the real current page origin. I changed the flow so the Next BFF extracts the trusted request origin (Origin / Referer) and sends it to the backend, and the backend now gives priority to that dynamic allowed_origins when creating the token. I also removed the old temporary proxy workaround.