I am using the " Token Based Auth" plugin in my Weweb app but I am running into an issue as the API call to fetch the user which is within the plugin settings doesn’t work. I suspect that it is because we don’t have that option to “Make this request through a server” which we do have when adding a REST API action.
As a result, I believe the API call to fetch the user is being sent as OPTIONS instead of a GET.
Is there a way to control this or find a solution to it?
Perhaps allow us to define the request type OR allow us to store the user object into the plugin’s used variables?
I think the OPTIONS call is a CORS preflight request.
The browser will automatically send a preflight request every time you try to send a request to a different origin, (unless it is a simple request).
It is automatic browser behaviour, weweb is not switching the request method.
The endpoint called should be able to handle this kind of requests.
Correct, but what’s strange is that the OPTIONS is not followed by another request even if the backend is sending something like a 200 OK response to the options.
I think just 200 OK is not enough. The response needs to have some CORS related headers (‘Access-Control-Allow-Origin’, ‘Access-Control-Allow-Methods’, ‘Access-Control-Allow-Headers’).
Of course you can check if this is what is happening in the network panel of the developer tool in your browser.
We are returning these values with the response as you have suggested.
On Postman, it is receiving the headers from our BE correctly.
No it doesn’t work @dorilama
Perhaps if we had that toggle to send the request through the WeWeb server that could resolve it…
Any error in the console?
Is this happening when you use the action ‘Fetch User’?
If this is the case the problem may be that weweb is fetching with a
GET method but on the preflight request your server is allowing only
POST. ‘Access-Control-Allow-Methods’ should include
Thanks @dorilama, good question on the OPTIONS response allowing GET, will check that.
Haven’t checked the console response and will do that too!
Not yet, I am planning to check the console → Network tab from the project public URL because trying to check that from within Weweb shows some Facebook call which I don’t understand.
Checked the Console and found this error on the production URL + many chunk vendor error (seems like WeWeb related?)
Access to XMLHttpRequest at ‘https://payflowly.com/dashboard/user/me’ from origin ‘https://my.payflowly.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: The ‘Access-Control-Allow-Origin’ header contains multiple values ‘*, *’, but only one is allowed.
Looks like the preflight request is failing because the backend is responding with 2 values for ‘Access-Control-Allow-Origin’. It should be just
* instead of
Hey @dorilama. That indeed was the issue and I was chasing our developer to fix that.
It was just fixed and all is working properly!
Not only did you point this out but the previous issues was also solved thanks to you (Not allowing Get for Options)
Many thanks for your help!
Nice one! Thanks so much for helping out with this @dorilama!
Fetch user isn’t working for me either. Does the user’s endpoint need to be a GET and return an accessToken and refreshToken? At the moment this is a POST for me.
My understanding is that the fetcUser action send a get request.
The problem in this thread was about correct CORS handling on the backend