react-native-debugger icon indicating copy to clipboard operation
react-native-debugger copied to clipboard

Cannot read Set-Cookie response header when network inspect enabled

Open rsouthgate opened this issue 5 years ago • 9 comments

Unsure if this is fixable here or a limitation of the underlying lib - electron?

Basically I need to read the Set-Cookie response headers in a fetch request. When the network inspect is disabled this is fine, but when enabled these headers are getting removed somewhere upstream.

React Native Debugger app version: 0.9.7 React Native version: 0.58.6 Platform: iOS Is real device of platform: Yes Operating System: macOS

rsouthgate avatar Mar 28 '19 01:03 rsouthgate

@rsouthgate this also happens to me, I'm on RN version 59.9, and RN debugger version 0.9.10

ichiyouji avatar Jul 23 '19 08:07 ichiyouji

@ichiyouji Yep, it's a limitation of the way network inspect extends the xmlhttprequest object - I guess originally coming from the browser world where that header is an instruction to the browser and isn't for the client app that would normally be running within the browser.

It's not specifically listed in these limitations: https://github.com/jhen0409/react-native-debugger/blob/master/docs/network-inspect-of-chrome-devtools.md#limitations but it's related to them.

When I last thought about it I came to the conclusion that this could be solved by using the RN fetch/xmlhttprequest interface across the RN bridge which would have the side effect of running the same code with debugging on and off... but that's a big ask.

At least when not inspecting network traffic but debugging everything else it is accessible so I could live with it.

rsouthgate avatar Jul 23 '19 21:07 rsouthgate

@rsouthgate I see, thanks for the insight

ichiyouji avatar Jul 24 '19 09:07 ichiyouji

@ichiyouji Yep, it's a limitation of the way network inspect extends the xmlhttprequest object - I guess originally coming from the browser world where that header is an instruction to the browser and isn't for the client app that would normally be running within the browser.

It's not specifically listed in these limitations: https://github.com/jhen0409/react-native-debugger/blob/master/docs/network-inspect-of-chrome-devtools.md#limitations but it's related to them.

When I last thought about it I came to the conclusion that this could be solved by using the RN fetch/xmlhttprequest interface across the RN bridge which would have the side effect of running the same code with debugging on and off... but that's a big ask.

At least when not inspecting network traffic but debugging everything else it is accessible so I could live with it.

Does that mean, that we cannot use cookie? Because after debugging a little I saw that there isnt any Set-cookie` header with network enabled

MusicalEcho avatar Dec 09 '19 15:12 MusicalEcho

@MusicalEcho the app I'm currently working on use cookie stored in async storage for authorization because it's using an API designed for the pre-existing web app.

Try turning off the network inspect and log the response.header on the console. If everything is correct, the Set-Cookie header should be present.

Screen Shot 2019-12-16 at 17 12 17

The downside is that when I'm debugging, I have to turn off network inspect when the app is invoking a request that returns a Set-Cookie header. If the network inspect is on, the Set-Cookie header will be missing as you described.

ichiyouji avatar Dec 16 '19 10:12 ichiyouji

Is there any plan to support can set cookies when open the network inspect feature when useing RND? @rsouthgate

LoverFancy avatar Sep 07 '21 10:09 LoverFancy

Following

philipjames44 avatar Jul 21 '22 03:07 philipjames44

A little bit information on this problem, in fact, its not a browser limitation. When we use the Network Inspect option all of the requests made by the Mobile app is proxied by localhost server build with webpack-dev-server, since that server is a localhost http server that try to reach a remotes services that fails on the security level so the Set-Cookie never been set correctly. That what i found.

TacticCoder avatar Jul 27 '22 09:07 TacticCoder

This needs to be explicitly mentioned in the docs; I suggest an item on the troubleshooting page, AND a mention in readme.md because for those of us it affects, it's important to be aware of.

I'm grateful to have this tool available, but not only is this a nuisance in using RND, it cost me fully two days in the middle of a large, time-sensitive app update. (Since I had changed so much code, it took me a long time to discover RND was the cause!)

BTW I'm on MacOS 11.6, RN 68.5, RND 0.13.

evangrim avatar Feb 13 '23 17:02 evangrim