The “I’m Under Attack” security level completely disables the OPTIONS method for CORS, it doesn’t work at all and only tries to load the verification page even if I have just verified my identity.
I am a bit foggy on the details here. https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it seems to go more into detail.
Wouldnt that request only be sent if the request originates from another domain? Would you have a sample URL?
The front-end is located at https://balz.io and the API is located at https://api-staging.balz.io, thus communicating with the API requires CORS functionality. It doesn’t seem Cloudflare likes this with UAM enabled.
And OPTIONS requests get sent to your naked domain or the api-staging host?
In this case the challenge probably only applies to your naked domain and not the host, hence the OPTIONS request still gets challenged. You could switch off IUA and create a challenging firewall rule which only applies to your naked domain.
I guess, but that defeats the purpose of using UAM to protect my API
IUA is generally intended for browser interactions and not proper API calls. You’d need to open a URL from that host in some way so that it passes the challenge, afterwards the calls should work too.
Just going to change some things so everything is on the same domain, thanks for the help though.
Actually the cookie appears to be issued for the entire domain, so I’d assume the challenge to work for your host too. I opened your main page but there was not call to that host. Is there any way to reproduce it?
Whoops, gave you a slightly incorrect URL. It was https://balz.io/development. I moved it to https://staging.balz.io for better concurrence and no need for CORS. API is located at https://staging.balz.io/api and Gateway is at https://staging.balz.io/gateway.
So everything is under “staging”?
In that case there shouldnt be an additional challenge, but I wouldnt expect OPTIONS requests either as everything is under the same origin. Which browser are you using? Under Firefox I wouldnt get any such requests.
Well now that it’s under the same origin i’m not encountering this error anymore, although its still odd that even though the cookie is shared over multiple origins, Cloudflare’s IAM page doesn’t seem to recognize it. Like I said, it’s fixed now with some readjustments.
In order to analyse that we would need a setup across different origins. But if it is working now, it is fixed I guess
This topic was automatically closed after 30 days. New replies are no longer allowed.