Cookie based authentication issues aggregation
See original GitHub issueEnvironment
[skip envinfo]
Reproducible Demo
Provided in corresponding issues
Description
Issues closed while still open. Cookie based authentication is at this moment not usable. This is partially due to the following issues:
- https://github.com/facebook/react-native/issues/23005 //TL;DR can only ever work with one cookie on Android
- https://github.com/facebook/react-native/issues/929 //TL;DR redirect: ‘manual’ doesnt work
These issues have been closed even though they are still open and very relevant. There’s more around cookies/fetch that i will try to hunt down in the following days. E.g one of the two platforms, i believe iOS , wont store cookies after app restart.
Conclusion
In general cookie based authentication is very problematic on multiple levels. If cookie based authentication is claimed implied to be supported on React Native and developers unknowingly structure their architecture around this these issues need attention. Otherwise people need to know before implementing a project using such an authentication mechanism as dozens of hours could be spend working on an architecture that is inevitably simply not supported.
This is not a matter of pointing fingers or demanding features. It is currently unfortunately misleading to leave people unaware of all these limitations as they might set out to create an architecture that’s unsupported as i have.
At the very least maybe we should revise the documentation of fetch
and explain how some things like “redirect:manual” dont work right now.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:61
- Comments:28 (3 by maintainers)
Top GitHub Comments
Hello, I had the same problem here and analysed the internal issue:
The problem is a combination of
NetworkingModule.java
and the usage ofWritableNativeMap
. The functiontranslateHeaders
maps the OKHTTP header objekt to a React Native header map. Headers with the same key was overridden because thehasKey
method always return false.https://github.com/facebook/react-native/blob/9895d011374e655bcaeb390167abafb9c01fef18/ReactAndroid/src/main/java/com/facebook/react/modules/network/NetworkingModule.java#L647-L661
That
hasKey
always return false is an implementation error inReadableNativeMap
andWritableNativeMap
(which extends the readable map). This native maps supports two different modes, which can be enabled and disabled for all maps with a static booleanuseNativeAccessor
.This flag defines if the ReadableNativeMap reads data from a native map or a internal (java.util.) HashMap.
But the problem was that WritableNativeMap always writes into the native map and never uses the (Readable) internal HashMap.
That was the reason why
hasKey
always return null ifuseNativeAccessor
was false and only one header was returned bytranslateHeaders
.Like said by @hey99xx in https://github.com/facebook/react-native/issues/21795#issuecomment-430384534 and by @Return-1 https://github.com/facebook/react-native/issues/23005#issuecomment-457107736 its possible to activate the this native accessor, if you add this code to your own/project
MainActivity.java
:Add this imports:
And this add the beginning of the
createReactActivityDelegate
method, before your application was loaded.For me this works fine. But notice that this global flag may cause some other troubles.
I also started to fix this behaviour in the latest React Native 0.59.3 release, but notice than that the master version of ReadableNativeMap/WritableNativeMap was already changed.
The commits https://github.com/facebook/react-native/commit/b257e06bc6c29236a1a19f645fb46b85b2ffc4d2 and https://github.com/facebook/react-native/commit/a062b34493f07b28378de2772914d838cb28e3d8 by FB eng @sahrens changed/removed the useNativeAccessor behaviour, so I hope this issue was also fixed with the next/upcoming minor release 0.60.0. 🙌
(I couldn’t test the new version yet, because running from the npm package (also with sourcecode changes) works fine for me, but the sourcecode version of RN let fail some of my 3rd party libraries. I’m looking forward for a RC of 0.60.0 and maybe will update this text here then.)
Great, will proceed with that. There’s more than cookies, for example a redirect cannot be omitted with
redirect:manual
. Im on it.