Problem with Chrome plugin and CORS

I'm having problems debugging Angular app in Chrome ( 62.0.3202.89) with JetBrains IDE Support plugin (2.0.9) and Intellij Idea Ultimate (2017.2.6).

The app calls some 3rd party URL to get access token on startup, but whenever I connect idea debugger the request fails:

Failed to load <service url>: Request header field x-ijt is not allowed by Access-Control-Allow-Headers in preflight response.

The service sends header:

Access-Control-Allow-Headers: accept, content-type, cookie, set-cookie
 
It seems like IDE support plugin adds "x-ijt" header to all requests which makes them fail if server responds with "Access-Control-Allow-Headers".
 
What is that header for and is there a way to prevent the plugin from sending it to some urls? The only workaround I've come up with is to run chrome with CORS disabled but that doesn't seem like a good solution.
 
 
17 comments
Comment actions Permalink

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

4
Comment actions Permalink

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.

0
Comment actions Permalink

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

0
Comment actions Permalink

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.

1
Comment actions Permalink

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...

1
Comment actions Permalink

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?

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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...

0
Comment actions Permalink

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:

 

0
Comment actions Permalink

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

0
Comment actions Permalink

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

0
Comment actions Permalink

I get this now as well. 

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

0
Comment actions Permalink

@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.

1
Comment actions Permalink

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

0
Comment actions Permalink

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

0
Comment actions Permalink

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.

1

Please sign in to leave a comment.