Problem with Chrome plugin and CORS

This header is sent for request signing to prevent requests from outside from being rejected; should not be sent if unsigned requests are allowed.
Will be fixed in 2017.3 - when Allow unsigned requests is enabled in Settings | Build, Execution, Deployment | Debugger, this header won't be sent.

Note that 2017.3 allows debugging without extension

I have Allow unsigned requests allowed and it still sends that header so if I understand it correctly - it's a bug and will be fixed in 2017.3?

UPDATE - I've installed IDEA 2017.3 RC3 but the header is still being sent regardless of Allow unsigned requests settings, so I guess I'll have to wait for final release.

Hmm... Did you try debugging without Chrome extension?

Yes, I uninstalled the plugin and just to be extra sure rebooted computer. The debugging itself works - it launches new window and stops at breakpoints, but some requests fail due to that header.

Updated to 2017.3 release version and the problem is not fixed, the header is still being sent despite having Allow unsigned requests turned on. 

I'm just wondering why noone else is experiencing this issue, calling service with Access-Control-Allow-Headers seems like pretty standard thing to do and it makes the debug feature in IDEA useless. Can someone please test this, maybe it's just some problem with my IDEA configuration or something...

We did test this, and haven't faced problems in 2017.3. can you share a sample app we can use to recreate the issue?

I'm trying to put together sample app but I'm struggling to find some public facing service returning proper headers so I'll probably have to deploy some mock service somewhere.

I think the problem is that the service I'm having trouble with makes redirect, so the flow looks like this:

• GET request to some URL, server returns Access-Control-... headers and 302 redirect to some other URL
• Chrome makes OPTIONS preflight request with "x-ijt" header to redirect URL, server again returning Access-Control-... headers (with Access-Control-Allow-Headers)
• Chrome fails with error message 'Failed to load <url>: Request header field x-ijt is not allowed by Access-Control-Allow-Headers in preflight response.'

When not debugging, the "x-ijt" header is not added to the request and everything works.

Ok, here's simple way to reproduce it, open this URL in browser and hit "Send Request". It will pass, but if you debug the page from webstorm, the request fails.

Hmmm... But this one is completely different. The error I can see is

Failed to load https://cors-test.000webhostapp.com/test.php: Redirect from 'https://cors-test.000webhostapp.com/test.php' to 'https://cors-test.000webhostapp.com/test2.php' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'https://www.test-cors.org' that is not equal to the supplied origin. Origin 'http://localhost:63342' is therefore not allowed access.

and it's not specific to debugging... It occurs because 'https://cors-test.000webhostapp.com' only accepts requests from 'https://www.test-cors.org', and won't accept requests from other servers...

Because you're running from localhost. You need to connect the debugger to that page I gave link to. Create new Javascript debug configuration and paste 'https://www.test-cors.org/#?client_method=GET&client_credentials=true&server_url=https%3A%2F%2Fcors-test.000webhostapp.com%2Ftest.php&server_enable=trueserver_credentials=false&server_tabs=remote' into URL, and then debug it. You should get new browser window connected to test-cors.org and then it will fail.

This is result in browser without debug:

This is result in browser while it's being debugged from webstorm:

Thanks, reproduced; the error is still different, but is obviously caused by "x-ijt" header being sent. Logged as https://youtrack.jetbrains.com/issue/WEB-30191, please follow it for updates

Update: checking "allow unsigned connections" seems to fix this.

I get this now as well. 

Allowing unsigned requests or disabling the IntelliJ Chrome plugin don't make a difference.

@Guenter

I got this as well after updating to WebStorm 2019.2. Checking "Allow unsigned requests" worked for me, but not until I restarted the IDE and associated processes. Hope that helps.

https://youtrack.jetbrains.com/issue/WEB-30191 is planned to be fixed in 2019.2.2

For now, enabling Allow unsigned requests is the only solution

@Haig that's possible. I changed the setting, but it didn't help, but today the error was gone.

Facing this issue as well. Enabling "Allow Unsigned Requests" in Build Execution and Deployment -> Debugger setting of Webstorm fixed it for now. I didn't need to restart Webstorm either, just the debugging process.