Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove mmkv cookie storage, use native cookie storage (cloudflare) #888

Closed
wants to merge 3 commits into from

Conversation

nguyd1
Copy link
Contributor

@nguyd1 nguyd1 commented Jan 9, 2024

  1. fetch on react native is made by the native networking stack so the cookie is stored in the device itself, no need for mmkv storage: https://stackoverflow.com/questions/41132167/react-native-fetch-cookie-persist

  2. android syncs the cookies every 5 min, if the app is killed during that time, the cookies will be lost and cloudflare will trigger again, we can fix this by using CookieManager.flush() to force cookie sync when the nav state changes on webview (occurs when cloudflare passes and navigates to website)

  3. the old implementation in useEffect was not storing any cookies because it is called right when webview opens and tries to obtain cookies before cloudflare ran, we needed to wait 5-10 seconds for the cloudflare pass to obtain the cf_clearance cookie and write to mmkv source storage

@nyagami
Copy link
Member

nyagami commented Jan 9, 2024

It's not true, you still have to provide headers to make network request.
You can test it by making a simple http server then request to it by React Native.

@nyagami
Copy link
Member

nyagami commented Jan 9, 2024

Plus, If Android couldstore the cookies it self and cookies are persisted (as the link), users just need to open source web in Chrome or any browser, then back to the app and they should have cookies stored in device, no need to open webview in app.
But in fact that it didnt work .

@nguyd1
Copy link
Contributor Author

nguyd1 commented Jan 9, 2024

It's not true, you still have to provide headers to make network request. You can test it by making a simple http server then request to it by React Native.

yes the fetch is still sending the user-agent headers, it is also sending the cookies via native storage, i tested the changes on my local and it is working but u can take a look if i am missing something

when i was debugging on main earlier i was noticing the cookies were not added to the headers from the mmkv storage but still passed after webview cloudflare authentication, leading me to find the points above:
image
image

@nguyd1
Copy link
Contributor Author

nguyd1 commented Jan 9, 2024

Plus, If Android couldstore the cookies it self and cookies are persisted (as the link), users just need to open source web in Chrome or any browser, then back to the app and they should have cookies stored in device, no need to open webview in app. But in fact that it didnt work .

i think this is possible if we use sharedCookiesEnabled on the webview component but ill have to test it out

update: researched this and i think the native cookie storage is per each app and not centralized which makes sense for privacy, also even if they were centralized then the user agents would not match between browser and lnreader which is required for the cloudflare cf_clearance cookie to work

@nguyd1
Copy link
Contributor Author

nguyd1 commented Jan 9, 2024

facebook/react-native@274c5c7

this is the commit that adds a persistent cookie storage and shares cookies between the webview and the react app

@nyagami
Copy link
Member

nyagami commented Jan 12, 2024

Confirmed. React Native helps us to add Cookie if not provided in headers.
Thanks

@rajarsheechatterjee
Copy link
Member

We are also sending the cookie from MMKV in FastImage's headers. We should also remove them if they're working as expected.

Also thanks for you recent contributions. 🎉

@nguyd1 nguyd1 closed this Jan 13, 2024
@nguyd1 nguyd1 deleted the bugfix/remove-cookie-storage branch January 13, 2024 15:43
@nguyd1 nguyd1 restored the bugfix/remove-cookie-storage branch January 13, 2024 15:43
@nguyd1
Copy link
Contributor Author

nguyd1 commented Jan 13, 2024

#896 new pr i accidentally closed this and cant reopen it

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants