My client side web app is written using Angular, and server side is AWS API gateway.
I'm getting the error:
Access to XMLHttpRequest at <my destiniation> from origin <my origin> has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Where <my destination>
and <my origin>
are not the same domain.
The problem is that I do have CORS setup to support this. My setup uses a preflight OPTIONS request, followed by a PUT request (the PUT is what is failing with a 403, and console shows the CORS error). The response from the OPTIONS request does in fact include access-control-allow-origin: *
and the strangest thing is that my PUT request will only fail if one (or more) of my URL parameter arguments contains a %23 in it (for example, as the result of URL encoding a # symbol).
Does anyone know why special characters in URL parameters would trigger a CORS error while the exact same request without the special characters passes CORS without any issue? What could I be missing?
Thanks to the help from sideshowbarker I was able to solve this. It turns out that the CORS error was in fact a red herring.
After digging a bit deeper, I learned that the AWS signature wasn't matching (but only when including special characters), and I found out that I needed to double encode my parameters in order for the signature to be calculated properly. I did this with decodeURIComponent()
on each parameter that might contain special characters, and then I used decodeURI()
on the resulting entire URL (effectively double encoding the problematic parameters). The signature now passes and the requests succeeds.
This problem/solution is probably unique to how my client side app (in Angular) is working with AWS signatures, but it may come in handy for someone else who is getting similar errors.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With