Cookie based authentication issues aggregation #23185
Comments
This comment has been minimized.
This comment has been minimized.
|
I have the same issue as mentioned in #23005. Example using postman:
Example RN iOS: Example RN Android:
|
|
Yes, this is still a problem, and regarding your comment in other issue
you're absolutely right, it's a recently introduced bug in WritableNativeMap / WritableNativeArray classes. See #21795 (comment) #21795 (comment) #22064 (comment). |
kelset
changed the title
can you point out to me where this "claim" is written in the documentation? |
|
Surely. On the documentation found here:
However |
|
Then I guess we should add in the docs, where we link to fetch, that cookies are not fully supported? I mean, there is no direct reference to cookies in the RN docs so this phrase
is a bit passive-aggressive I feel 😅 Have you tried using third-party libraries? Do they use fetch? |
|
@kelset i apologise, implied is definitely a better word for it. I hold immense respect both for you ( i am familiar with your contributions ) and the rest of the team and as i've already solved this issue by migrating to a token based architecture it is only for the purposes of helping others that i'm bringing this up. How would you suggest proceeding from here? I can go ahead and edit the documentation referencing the corresponding issues but i am unaware of the processes as upon resolution documentation should be re-revisited. Thanks so much for attending to this. Hopefully i will find some time to contribute to this issue myself. |
kelset
added
📮Known Issues
As I mentioned above, probably the immediate step to be taken would be to clarify in the documentation that while we use In the meantime for now I've added the "known issues" label which should help framing this problem in the right perspective. |
|
Great, will proceed with that. There's more than cookies, for example a redirect cannot be omitted with |
|
Hi, is this issue still being looked into? Thanks |
|
@rheng001 not actively by me, i did add some documentation which is merged warning readers against usage which should at least save people a few hours. |
|
@Return-1 is there a resolution plan for this issue in like 0.59? I also think this is a recent outstanding issue. There are a number of referenced issues which end up in here. It would be nice to see some progress (some commits mb) referenced from this issue. |
|
I agree, It would be appreciated to see some references of this being addressed. |
|
AFAIK nobody's currently working on it. We'd appreciate some movement around this issue though, so please keep the comments going and send PRs if possible. |
|
Hello, I had the same problem here and analysed the internal issue: The problem is a combination of That 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 Like said by @hey99xx in #21795 (comment) and by @Return-1 #23005 (comment) its possible to activate the this native accessor, if you add this code to your own/project Add this imports: import com.facebook.react.bridge.ReadableNativeArray;
import com.facebook.react.bridge.ReadableNativeMap;And this add the beginning of the ReadableNativeArray.setUseNativeAccessor(true);
ReadableNativeMap.setUseNativeAccessor(true);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 b257e06 and a062b34 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.) |
|
Can confirm the duplicate-header-disappearance issue hasn't been fixed yet, and the workaround doesn't work anymore either. @sahrens |
|
I am using cookie based authentication. On RN 0.59.8 I manually set |
|
|
@Jyrno42 no quotation marks. |
|
This is what happens for me (Android):
|
#27066) Summary: Multiple `set-cookie` headers should be aggregated as one `set-cookie` with values in a comma separated list. It is working as expected on iOS but not on Android. On Android, only the last one is preserved The problem arises because `NetworkingModule.translateHeaders()` uses `WritableNativeMap` as the translated headers but uses both native and non-native methods. The mixup causes out of sync data that both sets of methods do no agree. A simple fix is to use `Bundle` as the storage and only convert it to `WritableMap` at the end in one go Related issues: #26280, #21795, #23185 ## Changelog [Android] [Fixed] - Fix multiple headers of the same name (e.g. `set-cookie`) not aggregated correctly Pull Request resolved: #27066 Test Plan: A mock api, https://demo6524373.mockable.io/, will return 2 `set-cookie` as follows: ``` set-cookie: cookie1=value1 set-cookie: cookie2=value2 ``` Verify the following will print the `set-cookie` with a value `cookie1=value1, cookie2=value2` ```javascript fetch('https://demo6524373.mockable.io/') .then(response => { console.log(response.headers); }); ``` On iOS, `set-cookie` will have `cookie1=value1, cookie2=value2` while on Android it will have `cookie2=value2` (preserving only the last one) Differential Revision: D18298933 Pulled By: cpojer fbshipit-source-id: ce53cd41d7c6de0469700617900f30a7d0914c26
#27066) Summary: Multiple `set-cookie` headers should be aggregated as one `set-cookie` with values in a comma separated list. It is working as expected on iOS but not on Android. On Android, only the last one is preserved The problem arises because `NetworkingModule.translateHeaders()` uses `WritableNativeMap` as the translated headers but uses both native and non-native methods. The mixup causes out of sync data that both sets of methods do no agree. A simple fix is to use `Bundle` as the storage and only convert it to `WritableMap` at the end in one go Related issues: #26280, #21795, #23185 ## Changelog [Android] [Fixed] - Fix multiple headers of the same name (e.g. `set-cookie`) not aggregated correctly Pull Request resolved: #27066 Test Plan: A mock api, https://demo6524373.mockable.io/, will return 2 `set-cookie` as follows: ``` set-cookie: cookie1=value1 set-cookie: cookie2=value2 ``` Verify the following will print the `set-cookie` with a value `cookie1=value1, cookie2=value2` ```javascript fetch('https://demo6524373.mockable.io/') .then(response => { console.log(response.headers); }); ``` On iOS, `set-cookie` will have `cookie1=value1, cookie2=value2` while on Android it will have `cookie2=value2` (preserving only the last one) Differential Revision: D18298933 Pulled By: cpojer fbshipit-source-id: ce53cd41d7c6de0469700617900f30a7d0914c26
|
@grabbou Thank you for fixing this issue. It is an important step in unlocking cookie based authentication for React Native which at this point is only partially usable and might lead up to teams having issues with setting up their architecture as i unforutnately faced in the past. I will attempt to re-update the documentation with this. If the issue below is also resolved, cookie-based authentication might be fully support from this point onwards. The issue is referenced on the original post and can be found in the following: Since at the time cookie based authentication was not a reality my team has migrated to token based however, solving the above issue might make it operational again and it could be claimed on the next release that it can be safely used from developers from this point onwards so i think it's an important thing to highlight. Thank you for the awesome work |
…s (#27066) Summary: Multiple `set-cookie` headers should be aggregated as one `set-cookie` with values in a comma separated list. It is working as expected on iOS but not on Android. On Android, only the last one is preserved The problem arises because `NetworkingModule.translateHeaders()` uses `WritableNativeMap` as the translated headers but uses both native and non-native methods. The mixup causes out of sync data that both sets of methods do no agree. A simple fix is to use `Bundle` as the storage and only convert it to `WritableMap` at the end in one go Related issues: facebook/react-native#26280, facebook/react-native#21795, facebook/react-native#23185 ## Changelog [Android] [Fixed] - Fix multiple headers of the same name (e.g. `set-cookie`) not aggregated correctly Pull Request resolved: facebook/react-native#27066 Test Plan: A mock api, https://demo6524373.mockable.io/, will return 2 `set-cookie` as follows: ``` set-cookie: cookie1=value1 set-cookie: cookie2=value2 ``` Verify the following will print the `set-cookie` with a value `cookie1=value1, cookie2=value2` ```javascript fetch('https://demo6524373.mockable.io/') .then(response => { console.log(response.headers); }); ``` On iOS, `set-cookie` will have `cookie1=value1, cookie2=value2` while on Android it will have `cookie2=value2` (preserving only the last one) Differential Revision: D18298933 Pulled By: cpojer fbshipit-source-id: ce53cd41d7c6de0469700617900f30a7d0914c26
facebook#27066) Summary: Multiple `set-cookie` headers should be aggregated as one `set-cookie` with values in a comma separated list. It is working as expected on iOS but not on Android. On Android, only the last one is preserved The problem arises because `NetworkingModule.translateHeaders()` uses `WritableNativeMap` as the translated headers but uses both native and non-native methods. The mixup causes out of sync data that both sets of methods do no agree. A simple fix is to use `Bundle` as the storage and only convert it to `WritableMap` at the end in one go Related issues: facebook#26280, facebook#21795, facebook#23185 ## Changelog [Android] [Fixed] - Fix multiple headers of the same name (e.g. `set-cookie`) not aggregated correctly Pull Request resolved: facebook#27066 Test Plan: A mock api, https://demo6524373.mockable.io/, will return 2 `set-cookie` as follows: ``` set-cookie: cookie1=value1 set-cookie: cookie2=value2 ``` Verify the following will print the `set-cookie` with a value `cookie1=value1, cookie2=value2` ```javascript fetch('https://demo6524373.mockable.io/') .then(response => { console.log(response.headers); }); ``` On iOS, `set-cookie` will have `cookie1=value1, cookie2=value2` while on Android it will have `cookie2=value2` (preserving only the last one) Differential Revision: D18298933 Pulled By: cpojer fbshipit-source-id: ce53cd41d7c6de0469700617900f30a7d0914c26
|
A new cookie based issue that is still valid in |
Can concur this still exists and is an issue |
|
if this issue still exists, Can we use the below implementation? |
facebook#27066) Summary: Multiple `set-cookie` headers should be aggregated as one `set-cookie` with values in a comma separated list. It is working as expected on iOS but not on Android. On Android, only the last one is preserved The problem arises because `NetworkingModule.translateHeaders()` uses `WritableNativeMap` as the translated headers but uses both native and non-native methods. The mixup causes out of sync data that both sets of methods do no agree. A simple fix is to use `Bundle` as the storage and only convert it to `WritableMap` at the end in one go Related issues: facebook#26280, facebook#21795, facebook#23185 ## Changelog [Android] [Fixed] - Fix multiple headers of the same name (e.g. `set-cookie`) not aggregated correctly Pull Request resolved: facebook#27066 Test Plan: A mock api, https://demo6524373.mockable.io/, will return 2 `set-cookie` as follows: ``` set-cookie: cookie1=value1 set-cookie: cookie2=value2 ``` Verify the following will print the `set-cookie` with a value `cookie1=value1, cookie2=value2` ```javascript fetch('https://demo6524373.mockable.io/') .then(response => { console.log(response.headers); }); ``` On iOS, `set-cookie` will have `cookie1=value1, cookie2=value2` while on Android it will have `cookie2=value2` (preserving only the last one) Differential Revision: D18298933 Pulled By: cpojer fbshipit-source-id: ce53cd41d7c6de0469700617900f30a7d0914c26
|
Can concur this still exits and is an issue: What I did:
I assume that
My expected result is: The WebSocket handshake should pass. My actual result is: The WebSocket handshake got denied (AcessDeniedException). It turns out that the WebSocket handshake does not contain Are React Native going to support What I've found:
Question:
|
|
My team has also run into this issue, and it was extremely challenging to debug. We were using Our function looks like this: axios.get('https://some-url-to-our-service.com', {
headers: {
'Content-Type': 'application/json',
Cookie: `session_token=${tokenVariable}; userID=${userIDVariable};`,
},
})
.then((response) => resolve(response))
.catch((error) => reject(error));This code worked in all of our Jest specs, including integration specs that actually called the production server. We also have a Postman set up that we use to test, debug, and otherwise hack on our backend services. Using the same But in the app, we were getting a bunch of 401 authentication errors. The server wasn't recognizing our cookies. I tested this using plain Then I found this thread and specifically #23185 (comment). With I haven't gotten around to patching our Axios call yet, but based on this issue, I think the Axios equivalent of If you're here and you're using Axios in React Native with cookie based authentication, you might want to try something that looks like: axios.get('https://some-url-to-our-service.com', {
headers: {
'Content-Type': 'application/json',
Cookie: `session_token=${tokenVariable}; userID=${userIDVariable};`,
},
withCredentials: false,
})
.then((response) => resolve(response))
.catch((error) => reject(error));I haven't tested that yet, but if I do, I will try to follow up here and confirm the fix. I don't know what else RN should or can do here. I'm glad that I was able to find this thread from the link in the Thanks to everyone in this thread, I hope my comment can help someone out in the future. EDIT 1: I did a hotfix on my local machine and |
In some scenario (mainly in production) we observed that cookie was duplicated in the HTTP headers. Also both cookies were separated by a comma instead of a semicolon This form is not supported by cozy-stack and the result is that the cozy-stack consider the request is not cookie-authenticated So when calling `/apps/:slug/open`, a new generated cookie would be returned instead of the provided one as expected in #277 To fix this we want to specify `credentials:omit` into the fetch options, this would prevent react-native to inject a copy of the same cookie More info: facebook/react-native#23185 (comment)
In some scenario (mainly in production) we observed that cookie was duplicated in the HTTP headers. Also both cookies were separated by a comma instead of a semicolon This form is not supported by cozy-stack and the result is that the cozy-stack consider the request is not cookie-authenticated So when calling `/apps/:slug/open`, a new generated cookie would be returned instead of the provided one as expected in #277 To fix this we want to specify `credentials:omit` into the fetch options, this would prevent react-native to inject a copy of the same cookie More info: facebook/react-native#23185 (comment)
In some scenario (mainly in production) we observed that cookie was duplicated in the HTTP headers. Also both cookies were separated by a comma instead of a semicolon This form is not supported by cozy-stack and the result is that the cozy-stack consider the request is not cookie-authenticated So when calling `/apps/:slug/open`, a new generated cookie would be returned instead of the provided one as expected in #277 To fix this we want to specify `credentials:omit` into the fetch options, this would prevent react-native to inject a copy of the same cookie More info: facebook/react-native#23185 (comment)
In some scenario (mainly in production) we observed that cookie was duplicated in the HTTP headers. Also both cookies were separated by a comma instead of a semicolon This form is not supported by cozy-stack and the result is that the cozy-stack consider the request is not cookie-authenticated So when calling `/apps/:slug/open`, a new generated cookie would be returned instead of the provided one as expected in #277 To fix this we want to specify `credentials:omit` into the fetch options, this would prevent react-native to inject a copy of the same cookie More info: facebook/react-native#23185 (comment)
|
@coolsoftwaretyler, hey Tyler, is this issue still a thing on the latest version of RN? |
|
@Kiura - I'm on React Native It also looks like the RN docs for |
Unfortunately cookies are problematic on RN - facebook/react-native#23185
|
We are on 0.71.8, we got this issue and fixed it with your workaround @coolsoftwaretyler |
|
Hi 👋 I believe I'm running into a similar problem as this thread describes - has anyone got any suggestions for the best way to 'prove' what I believe to be happening? Or a different explanation? TLDR; I don't think tools like Flipper and Proxyman are showing the 'automatic' cookies added to network requests at the native level. What's the best way to see them (or disprove my theory?) RN: 0.71.11 Our app does two separate things depending on the screen the user is on. It either: 1) fetches server state and displays it on the UI natively, or 2) renders an embedded webview. On some of these webviews, we set some specific cookies relevant to the URL for those specific webviews. The cookies are set using the react-native-cookies When the user then navigates from an embedded webview screen to a native screen where a network request to the server is made, I believe that those cookies set during the embedded webview rendering are also being set on the subsequent network requests for that server state - these requests then fail as a direct result of the inclusion in the request of a cookie set during (and intended for) the embedded webview render. I understand that setting cookies via However, the perplexing thing to me is, I can't prove it. Although I can prove by the behaviour of our app that those native cookies intended for the webview are also being given to subsequent native network requests, I can't actually see literal, visual proof of their inclusion in those subsequent network requests. I've tried inspecting the requests using Flipper, RN Debugger, Proxyman, and Axios interceptors, and none of them reveal the cookie that I believe must be included on the request else the request wouldn't fail for that specific reason. Setting So does anyone have any suggestions of how I might inspect the network request at the correct level/time in order to prove my theory about the 'invisible' inclusion of some cookies? Or any alternative explanations for why I might be seeing the behaviour described in case I'm barking up the wrong tree with it? Thanks for any help. |
and others
Environment
[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:
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
claimedimplied 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
fetchand explain how some things like "redirect:manual" dont work right now.The text was updated successfully, but these errors were encountered: