Parse-SDK-JS icon indicating copy to clipboard operation
Parse-SDK-JS copied to clipboard

Refused to get unsafe header "access-control-expose-headers" on Chrome

Open alljinx opened this issue 2 years ago • 10 comments

New Issue Checklist

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

alljinx avatar Nov 28 '23 08:11 alljinx

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

PPHelios avatar Nov 28 '23 21:11 PPHelios

I have the same issue also, I've tried different CORS settings on server side but no luck.

magnacartatron avatar Nov 29 '23 08:11 magnacartatron

also getting it now

REPTILEHAUS avatar Dec 26 '23 17:12 REPTILEHAUS

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.

mtrezza avatar Dec 26 '23 19:12 mtrezza

Also I have the same error !!! I wait for the solution :)

jcabezasia avatar Jan 26 '24 14:01 jcabezasia

@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 :)

ajmeese7 avatar Mar 02 '24 16:03 ajmeese7

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.

mtrezza avatar Mar 02 '24 20:03 mtrezza

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.

mortenmo avatar Mar 17 '24 13:03 mortenmo

Would you want to open a PR?

mtrezza avatar Mar 17 '24 14:03 mtrezza

🎉 This change has been released in version 5.1.0-alpha.5

parseplatformorg avatar Apr 22 '24 20:04 parseplatformorg