Parse-SDK-JS
Parse-SDK-JS copied to clipboard
Refused to get unsafe header "access-control-expose-headers" on Chrome
New Issue Checklist
- [x] I am not disclosing a vulnerability.
- [x] I am not just asking a question.
- [x] I have searched through existing issues.
- [x] I can reproduce the issue with the latest versions of Parse Server and the Parse JS SDK.
Issue Description
Latest Parse SDK (v4.3.1) from "localhost:4200" raise systematically a chrome error Refused to get unsafe header "access-control-expose-headers" when using Cloud.run(...) against a Parse-Server also hosted on localhost.
Issue does not exist with Parse SDK v4.3.0.
Steps to reproduce
Launch a Parse-Server (last version >= v6.4.0). Use Chrome (or Brave) to make a call to Parse-Server, using the Parse SDK v4.3.1 with the Cloud.run(...) function.
Actual Outcome
Raise a Chrome error Refused to get unsafe header "access-control-expose-headers" for each call using Cloud.run(...)
Expected Outcome
No error as v4.3.0
Environment
NodeJS >= 18
Server
- Parse Server version:
v6.4.0 - Operating system:
Windows 10 - Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc):
Local
Database
- System (MongoDB or Postgres):
Postgres - Database version:
15.x - Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc):
Local
Client
- Parse JS SDK version:
4.3.1
Thanks for opening this issue!
- 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.
I have the same issue
I have the same issue also, I've tried different CORS settings on server side but no luck.
also getting it now
This header was added in https://github.com/parse-community/Parse-SDK-JS/pull/2033. Maybe someone could investigate this to find out what's wrong with the header implementation. Added a bounty.
Also I have the same error !!! I wait for the solution :)
@mtrezza I experienced this as well, and with some digging I found a Stack Overflow explanation and a possible solution:
'access-control-expose-headers': 'Content-Encoding, X-Parse-Job-Status-Id, X-Parse-Push-Status-Id',
MDN says that Content-Encoding should be used to expose a non-CORS-safelisted response header. I haven't tried adding this at the front of the code in the mentioned PR line and spinning up a Docker instance to test it myself, but it's definitely worth a shot!
Would love to see this fixed, if someone could test this possible solution out that would be great :)
Would you want to open a PR to fix this? We could then release an alpha version of the bug fix and others could easily test this out as the pre-release will be published on npm. We also would need a test to prevent a regression bug.
According to this article (https://trackjs.com/blog/refused-unsafe-header/), this error is show in chrome/chromium on any attempt at accessing a header that isn't present.
Changing
if (typeof xhr.getResponseHeader === 'function' && xhr.getResponseHeader('access-control-expose-headers')) {
to:
if (typeof xhr.getResponseHeader === 'function' && xhr.getAllResponseHeaders().indexOf('access-control-expose-headers') >= 0) {
This fixed it for me. it is worth noting it does seem to be just a console message and doesn't really hurt the execution. Previous version of the code did use getAllResponseHeaders as well.
Would you want to open a PR?
🎉 This change has been released in version 5.1.0-alpha.5