Cookie based authentication issues aggregation #23185

Return-1 · 2019-01-28T09:58:19Z

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:

Fetch only brings latest value of same-name headers on Android, works on iOS. #23005 //TL;DR can only ever work with one cookie on Android
[XMLHttpRequest] Making HTTP requests to redirects. #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.

The text was updated successfully, but these errors were encountered:

cirediew · 2019-01-28T13:44:29Z

I have the same issue as mentioned in #23005.
Using the fetch functionality to do an authentication post returns a header with two cookies with the same name. On iOS these are concatenated. On Android only the second cookie is returned.

Example using postman:

set-cookie →token=XXXXXXXXXXXXXXXXXXXXXX; expires=Mon, 27-Jan-2020 12:45:43 GMT; Max-Age=31449600; Path=/

set-cookie →session=YYYYYYYYYYYYYYYYYYYYYYYYY; httponly; Path=/

Example RN iOS:
"set-cookie": "token=XXXXXXXXXXXXXXXXXXXXXX; expires=Mon, 27-Jan-2020 12:47:58 GMT; Max-Age=31449600; Path=/, session=YYYYYYYYYYYYYYYYYYYYYYYYY; httponly; Path=/"

Example RN Android:
"set-cookie": "session=YYYYYYYYYYYYYYYYYYYYYYYYY; httponly; Path=/"

React Native Environment Info:
System:
OS: Windows 10
CPU: (4) x64 Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz
Memory: 4.83 GB / 15.68 GB
Binaries:
npm: 6.0.0 - C:\Program Files\nodejs\npm.CMD

hey99xx · 2019-01-29T06:16:16Z

Yes, this is still a problem, and regarding your comment in other issue

means that it's a problem with the data structure used maybe?

you're absolutely right, it's a recently introduced bug in WritableNativeMap / WritableNativeArray classes. See #21795 (comment) #21795 (comment) #22064 (comment).

kelset · 2019-01-29T08:52:13Z

If cookie based authentication is claimed to be supported on React Native

can you point out to me where this "claim" is written in the documentation?

Return-1 · 2019-01-29T09:20:25Z

Surely. On the documentation found here:
https://facebook.github.io/react-native/docs/network

React Native provides the Fetch API for your networking needs. Fetch will seem familiar if you have used XMLHttpRequest or other networking APIs before. You may refer to MDN's guide on Using Fetch for additional information.

However fetch does not support all the options as described at MDN. And since the only documentation provided on how to use it is MDN's site it follows that things like credentials:omit are supported by the networking layer.

kelset · 2019-01-29T10:34:31Z

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

cookie based authentication is claimed to be supported on React Native

is a bit passive-aggressive I feel 😅

Have you tried using third-party libraries? Do they use fetch?

Return-1 · 2019-01-29T11:06:28Z

@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 · 2019-01-29T11:22:58Z

I can go ahead and edit the documentation referencing the corresponding issues

As I mentioned above, probably the immediate step to be taken would be to clarify in the documentation that while we use fetch, there is not full support for cookies. And link to this issue as reference? Here's the link to the repo & file to change, if you can do a PR it would be lovely: https://github.com/facebook/react-native-website/blob/master/docs/network.md

In the meantime for now I've added the "known issues" label which should help framing this problem in the right perspective.

Return-1 · 2019-01-29T11:26:57Z

Great, will proceed with that. There's more than cookies, for example a redirect cannot be omitted with redirect:manual. Im on it.

rheng001 · 2019-03-01T23:53:26Z

@Return-1

Hi, is this issue still being looked into? Thanks

Return-1 · 2019-03-02T06:52:29Z

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

nyilmaz · 2019-03-04T06:54:45Z

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

rheng001 · 2019-03-16T00:42:13Z

I agree,

It would be appreciated to see some references of this being addressed.

thymikee · 2019-03-19T14:05:23Z

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.

christoph-jerolimov · 2019-04-04T09:38:15Z

Hello, I had the same problem here and analysed the internal issue:

The problem is a combination of NetworkingModule.java and the usage of WritableNativeMap. The function translateHeaders maps the OKHTTP header objekt to a React Native header map. Headers with the same key was overridden because the hasKey method always return false.

react-native/ReactAndroid/src/main/java/com/facebook/react/modules/network/NetworkingModule.java

Lines 647 to 661 in 9895d01

    
           private static WritableMap translateHeaders(Headers headers) { 
        
             WritableMap responseHeaders = Arguments.createMap(); 
        
             for (int i = 0; i < headers.size(); i++) { 
        
               String headerName = headers.name(i); 
        
               // multiple values for the same header 
        
               if (responseHeaders.hasKey(headerName)) { 
        
                 responseHeaders.putString( 
        
                     headerName, 
        
                     responseHeaders.getString(headerName) + ", " + headers.value(i)); 
        
               } else { 
        
                 responseHeaders.putString(headerName, headers.value(i)); 
        
               } 
        
             } 
        
             return responseHeaders; 
        
           }

That hasKey always return false is an implementation error in ReadableNativeMap and WritableNativeMap (which extends the readable map). This native maps supports two different modes, which can be enabled and disabled for all maps with a static boolean useNativeAccessor.

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 if useNativeAccessor was false and only one header was returned by translateHeaders.

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 MainActivity.java:

Add this imports:

import com.facebook.react.bridge.ReadableNativeArray;
import com.facebook.react.bridge.ReadableNativeMap;

And this add the beginning of the createReactActivityDelegate method, before your application was loaded.

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

pinstripe-potatohead · 2019-08-22T21:11:15Z

Can confirm the duplicate-header-disappearance issue hasn't been fixed yet, and the workaround doesn't work anymore either. @sahrens

guliash · 2019-09-26T08:33:07Z

I am using cookie based authentication. On RN 0.59.8 I manually set Cookie: connect.sid=${ sessionId }, because on iOS cookie was not persisted by system.
Now I am updating from RN 0.59.8 to 0.60.0 and see on dev server that connect.sid cookie is being doubled like Cookie: connect.sid=${ sessionId }, connect.sid=${ sessionId }. That is breaking authentication, because ',' used as a delimeter. Is it expected behavior?

guliash · 2019-09-30T06:26:28Z

I am using cookie based authentication. On RN 0.59.8 I manually set Cookie: connect.sid=${ sessionId }, because on iOS cookie was not persisted by system.
Now I am updating from RN 0.59.8 to 0.60.0 and see on dev server that connect.sid cookie is being doubled like Cookie: connect.sid=${ sessionId }, connect.sid=${ sessionId }. That is breaking authentication, because ',' used as a delimeter. Is it expected behavior?

credentials: 'omit' solved my issue. But it was not needed before 0.60.0 on iOS.

#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

Return-1 · 2019-11-28T11:25:23Z

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

#929
#26311

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

rishabhpoddar · 2020-03-30T22:43:04Z

A new cookie based issue that is still valid in v0.62.0: Android's CookieJar (JavaNetCookieJar) makes it impossible to use cookies during development

stephanoparaskeva · 2020-06-14T22:45:21Z

A new cookie based issue that is still valid in v0.62.0: Android's CookieJar (JavaNetCookieJar) makes it impossible to use cookies during development

Can concur this still exists and is an issue

miladr0 · 2020-09-07T19:00:13Z

if this issue still exists, Can we use the below implementation?
https://build.affinity.co/persisting-sessions-with-react-native-4c46af3bfd83

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

jasonrichdarmawan · 2021-01-26T10:23:04Z

Can concur this still exits and is an issue:

What I did:

Fetch using React Native Fetch API. I created a SPA chat for Browser to prove it sends the Set-Cookie, the repository

fetch("localhost:8080", {
  method: "GET",
});

I assume that Set-Cookie should store the cookie in React Native. I use React Native Debugger to see check the cookies in Application > Cookies but it's empty, I assume that's not where you can find the Cookies?

Establish a WebSocket connection

const stompConfig = {
  brokerURL,
  onConnectCallback, // subscribe
  debugCallback
}
const stompClient = new StompJs.Client(stompConfig);
stompClient.activate();

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

Are React Native going to support cookie-based authentication soon? I need not to use JWT (for functional purposes, I need to be able to invalidate session, etc).

What I've found:

credentials: 'omit' actually get the Set-Cookie header in Response, while credentials: 'include', credentials: 'same-origin' or without the credentials key did not receive the Set-Cookie header in Response.

This is the response.headers with credentials: 'omit'

[Tue Jan 26 2021 19:54:03.771]  LOG      {"map": {"cache-control": "no-cache, no-store, max-age=0, must-revalidate", "connection": "keep-alive", "content-length": "1406", "content-type": "text/html;charset=UTF-8", "date": "Tue, 26 Jan 2021 12:54:03 GMT", "expires": "0", "keep-alive": "timeout=60", "pragma": "no-cache", "set-cookie": "XSRF-TOKEN=e4a9c264-b887-4869-a55b-64fac6d0549d; Path=/", "x-content-type-options": "nosniff", "x-frame-options": "DENY", "x-xss-protection": "1; mode=block"}}

This is the response from curl -v localhost:8080

* Rebuilt URL to: localhost:8080/
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 302
< Set-Cookie: XSRF-TOKEN=bf141a5d-9d25-4945-99b9-8d7b96e08237; Path=/
< Set-Cookie: JSESSIONID=877F42328F07BDCA550D7C447CE8C603; Path=/; HttpOnly
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< Location: http://localhost:8080/login
< Content-Length: 0
< Date: Tue, 26 Jan 2021 13:05:15 GMT
<
* Connection #0 to host localhost left intact

Question:

Where can I see the cookies?
In Browser you can open Developer tools > Application > Cookies. I have tried to look in React Native Debugger > Application > Cookies but it always return empty.

coolsoftwaretyler · 2022-06-07T02:40:30Z

My team has also run into this issue, and it was extremely challenging to debug. We were using axios with React Native 0.64.3 along with cookie based authentication.

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 tokenVariable and userIDVariable with that URL was working.

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 fetch, and it still wasn't working.

Then I found this thread and specifically #23185 (comment). With fetch omitting the credentials, everything started to work.

I haven't gotten around to patching our Axios call yet, but based on this issue, I think the Axios equivalent of credentials: omit is withCredentials: false.

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 fetch docs, but it definitely burned a day for me, which is too bad. At the end of the day, I get that headers and cookies can be hard (I am no stranger to CORS). I just kind of wish this had been a smoother experience.

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 withCredentials: false seems to be getting 200 responses with the data I would expect.

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)

Kiura · 2023-01-14T23:24:18Z

@coolsoftwaretyler, hey Tyler, is this issue still a thing on the latest version of RN?
With v2 of our API, we were planning to remove Authentication header-based JWT authentication, since storing the token in the cookie using the httpOnly param is better for security (at least in the browsers)

coolsoftwaretyler · 2023-01-14T23:54:17Z

@Kiura - I'm on React Native 0.69.7, so I can't speak to any versions more recent than that, but I will say I know that my comment is still relevant. A week or two ago, I ran into the same issue as I was making a refactor somewhere that didn't have appropriate test coverage, and I had accidentally removed my workaround.

It also looks like the RN docs for 0.71 have a note about cookie based authentication, so while I can't speak to it specifically, it seems reasonable that the issue is still there.

Unfortunately cookies are problematic on RN - facebook/react-native#23185

arenier · 2023-10-23T15:17:11Z

We are on 0.71.8, we got this issue and fixed it with your workaround @coolsoftwaretyler

je00037 · 2023-10-31T15:45:54Z

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
Axios: 0.27.2
react-native-cookies: 6.2.1

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

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 CookieManager causes those cookies to remain in existence in native platform cookie storage beyond the life of that webview they were set upon, and can see this using the .get() methods made available on CookieManager. So I can, kinda, understand why I'm seeing this behaviour.

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 withCredentials: false as suggested by @coolsoftwaretyler appears to have no effect in this case.

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.

shanekunz · 2024-08-29T14:26:52Z

idk if this is a similar problem to what people are reporting, but using fetch with credentials = 'omit' solved my cookie issues and let me set them to whatever. Otherwise React Native / Expo wouldn't send my first cookie value for some reason.
rough snippet:

    let storedCookies = await AsyncStorage.getItem(dotnet_cookie_name);
    if(isNative && storedCookies){
      storedCookies = JSON.parse(storedCookies);
      options.headers = {
        'Cookie': storedCookies.map(c => `${c.key}=${c.value}`).join('; ')
      };
      options.credentials = 'omit'; // 'include' can interfere with the cookies we just set manually in the headers
    }
    const response = await fetch(url, options);

Return-1 added the Bug Report label Jan 28, 2019

This comment has been minimized.

Sign in to view

react-native-bot added the 📋No Environment Info label Jan 28, 2019

kelset changed the title ~~Cookie based authentication issue aggregation + Issues got closed without resolution.~~ Cookie based authentication issues aggregation Jan 29, 2019

kelset added 📮Known Issues This indicates an issue that refers to a bug or limitation of RN that is not currently being handled and removed 📋No Environment Info labels Jan 29, 2019

react-native-bot added the Bug Report label Feb 5, 2019

hramos removed the Bug Report label Feb 6, 2019

cpojer mentioned this issue Mar 19, 2019

RN Issue Triage Group 3 #24030

Closed

kelset added the Help Wanted Issues ideal for external contributors. label Mar 19, 2019

react-native-bot added the Bug label May 4, 2019

hramos removed the Type: Bug Report label May 6, 2019

dorcyv mentioned this issue Oct 7, 2019

Fix issue with react-native cookie cesargutierrezo/react-native-odoo-promise-based#4

Merged

harrydema mentioned this issue Dec 16, 2019

Android set support? safaiyeh/react-native-cookie-store#1

Open

lorenjohnson mentioned this issue Oct 21, 2021

Use more secure JWTs for password reset and email verification Hylozoic/hylo-node#687

Closed

kz-takahashi mentioned this issue Nov 4, 2021

✨: 認証のADRを追加 ws-4020/mobile-app-crib-notes#531

Merged

2 tasks

drewvolz mentioned this issue Aug 8, 2022

Android course catalog does not download data StoDevX/AAO-React-Native#6288

Closed

Ldoppea mentioned this issue Sep 22, 2022

fix: Prevent cookie duplication when calling /apps/:slug/open cozy/cozy-flagship-app#425

Merged

1 task

hbriese added a commit to zallo-labs/zallo that referenced this issue May 16, 2023

Use noncess auth

4bb48ee

Unfortunately cookies are problematic on RN - facebook/react-native#23185

bacarybruno mentioned this issue Oct 2, 2023

Compatibility with Medusa 1.17 sessions adrien2p/medusa-plugins#99

Merged

vecchp mentioned this issue Oct 9, 2023

Using current_user endpoint to fetch the authenticated user BetterAngelsLA/monorepo#41

Merged

jho406 mentioned this issue Apr 15, 2024

Add React Native Support thoughtbot/superglue#45

Open

personalizedrefrigerator mentioned this issue Nov 21, 2024

2024-10-30 - Android Joplin Profiles NextCloud Issue laurent22/joplin#11292

Closed

personalizedrefrigerator mentioned this issue Jan 17, 2025

Android: Fixes #11292: Fix unable to sync with multiple Nextcloud accounts in different profiles laurent22/joplin#11674

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cookie based authentication issues aggregation #23185

Cookie based authentication issues aggregation #23185

Return-1 commented Jan 28, 2019 •

edited

Loading

This comment has been minimized.

cirediew commented Jan 28, 2019

hey99xx commented Jan 29, 2019

kelset commented Jan 29, 2019

Return-1 commented Jan 29, 2019

kelset commented Jan 29, 2019

Return-1 commented Jan 29, 2019

kelset commented Jan 29, 2019 •

edited

Loading

Return-1 commented Jan 29, 2019

rheng001 commented Mar 1, 2019

Return-1 commented Mar 2, 2019

nyilmaz commented Mar 4, 2019

rheng001 commented Mar 16, 2019 •

edited

Loading

thymikee commented Mar 19, 2019

christoph-jerolimov commented Apr 4, 2019

pinstripe-potatohead commented Aug 22, 2019

guliash commented Sep 26, 2019

guliash commented Sep 30, 2019

Return-1 commented Nov 28, 2019 •

edited

Loading

rishabhpoddar commented Mar 30, 2020

stephanoparaskeva commented Jun 14, 2020

miladr0 commented Sep 7, 2020

jasonrichdarmawan commented Jan 26, 2021 •

edited

Loading

coolsoftwaretyler commented Jun 7, 2022 •

edited

Loading

Kiura commented Jan 14, 2023

coolsoftwaretyler commented Jan 14, 2023

arenier commented Oct 23, 2023

je00037 commented Oct 31, 2023 •

edited

Loading

shanekunz commented Aug 29, 2024

Cookie based authentication issues aggregation #23185

Cookie based authentication issues aggregation #23185

Comments

Return-1 commented Jan 28, 2019 • edited Loading

Environment

Reproducible Demo

Description

Conclusion

This comment has been minimized.

cirediew commented Jan 28, 2019

hey99xx commented Jan 29, 2019

kelset commented Jan 29, 2019

Return-1 commented Jan 29, 2019

kelset commented Jan 29, 2019

Return-1 commented Jan 29, 2019

kelset commented Jan 29, 2019 • edited Loading

Return-1 commented Jan 29, 2019

rheng001 commented Mar 1, 2019

Return-1 commented Mar 2, 2019

nyilmaz commented Mar 4, 2019

rheng001 commented Mar 16, 2019 • edited Loading

thymikee commented Mar 19, 2019

christoph-jerolimov commented Apr 4, 2019

pinstripe-potatohead commented Aug 22, 2019

guliash commented Sep 26, 2019

guliash commented Sep 30, 2019

Return-1 commented Nov 28, 2019 • edited Loading

rishabhpoddar commented Mar 30, 2020

stephanoparaskeva commented Jun 14, 2020

miladr0 commented Sep 7, 2020

jasonrichdarmawan commented Jan 26, 2021 • edited Loading

What I've found:

Question:

coolsoftwaretyler commented Jun 7, 2022 • edited Loading

Kiura commented Jan 14, 2023

coolsoftwaretyler commented Jan 14, 2023

arenier commented Oct 23, 2023

je00037 commented Oct 31, 2023 • edited Loading

shanekunz commented Aug 29, 2024

Return-1 commented Jan 28, 2019 •

edited

Loading

kelset commented Jan 29, 2019 •

edited

Loading

rheng001 commented Mar 16, 2019 •

edited

Loading

Return-1 commented Nov 28, 2019 •

edited

Loading

jasonrichdarmawan commented Jan 26, 2021 •

edited

Loading

coolsoftwaretyler commented Jun 7, 2022 •

edited

Loading

je00037 commented Oct 31, 2023 •

edited

Loading