You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update App to support switching to QA environment and logging to Cloudflare Zero trust #91419
A quick note on expo-web-browser, the library that opens the Cloudflare login popup on web: I think we should stick with it. It already handles almost everything we need, mobile will use the same API, so we keep a single auth flow across platforms, and it's already been running in production on web for the final step of the SAML logout flow.
That said, it did need a small workaround. Cloudflare's redirect chain breaks the mechanism the popup uses to report the result back to the main window, causing the auth flow to hang without any error. To work around this, I added a small web-only helper that lets the library complete the flow. It's not a second implementation: the library still owns the entire auth flow, and we simply receive the result through a different channel. It works reliably now across several local runs. The helper does lean on library internals that could change in a future version, so the unit tests reproduce the original hang, meaning a version bump that breaks this fails the suite instead of quietly hanging the flow.
For anyone interested in the details: under normal circumstances, the popup sends the result back via postMessage using window.opener. Somewhere in Cloudflare's redirect chain, the popup loses its window.opener, so the message has nowhere to go. Fortunately, just before sending the postMessage, expo-web-browser also stores the callback URL in localStorage, which remains accessible regardless of what happens to window.opener. The main window now listens for that value instead, while an orphaned popup closes itself after writing it. The workaround is about 100 lines of code and depends on a couple of localStorage key names used by expo-web-browser@56.0.5.
Regarding this popup issue, I wonder if popup is preferred/required option here. If not, we could redirect to CF in current tab (full-page redirect) and this would probably allow us to overcome this expo-web-browser issue entirely. cc: @iwiznia
I also discovered that we only perform SAML sign-outs via expo-web-browser. Sign-in uses full-page redirect as well so I would stick to this approach for CF ZeroTrust. I'll update design doc accordingly. From other things, we're starting "proper" implementation phase with @JakubKorytko. I'll be working on mobile side. He'll be working on web
Quick QA update: I'm still working through these problems with QA's Cloudflare sign-in:
Log loop. Without a Cloudflare session, log requests are rejected. Each rejection writes an alert, which sends another log request, which is rejected too. It repeats about once a second for as long as the tab is open.
Refused renewals. When Cloudflare refuses to renew a session, the tab keeps trying the dead one, and every other tab shares that same stored copy.
Requests without a session. Cloudflare rejects them, and a rejected sign-in step is retried up to 10 times and never succeeds.
Signed-in testers. If the Cloudflare session ends while someone is signed in, their requests fail until a reload.
When the Cloudflare sign-in goes wrong:
Back or Deny on the Cloudflare page sends the tester straight back to it, every time.
A failed sign-in leaves a typed code loading for about 43 seconds, or shows "Couldn't retrieve account details" at the email step.
A magic link can be sent twice, so the tester is signed in but sees the "enter the code from the original device" screen.
The email field comes back empty after the Cloudflare page.
Once I've figured these out I'll probably leave a few comments on the design doc, but I'm still working out how best to solve them.
Quick update! I've stopped working on the feature branch for now.
While going through the problems from my last update, I kept running into cases the design doc doesn't cover. There were too many to just figure out as I go, and a lot of them need an actual decision. So I started my own design doc for them. It's still a draft and I'm adding to it.
It builds on the feature branch, which follows the original design doc. The PRs that already merged were mostly prep work: refactoring, tooling, and checking that the connection to Cloudflare works. The branch doesn't handle a lot of edge cases yet, especially around errors. So far the draft covers:
Which requests can reach QA without a Cloudflare session
When the app sends you to the Cloudflare sign-in
Keeping the Cloudflare session when the app clears its own data
Handling errors when the Cloudflare sign-in goes wrong
Activity
iwiznia commentedon May 26, 2026
mateuuszzzzz commentedon Jun 8, 2026
I gave it a read. I'll be preparing implementation plan based on design doc. I'll post any updates in this issue
sharabai commentedon Jul 30, 2026
@iwiznia Hi! I'll be OOO starting tomorrow, so here's a quick update on the work I've been doing for the POC for web with CF Zero Trust on our fork.
A quick note on
expo-web-browser, the library that opens the Cloudflare login popup on web: I think we should stick with it. It already handles almost everything we need, mobile will use the same API, so we keep a single auth flow across platforms, and it's already been running in production on web for the final step of the SAML logout flow.That said, it did need a small workaround. Cloudflare's redirect chain breaks the mechanism the popup uses to report the result back to the main window, causing the auth flow to hang without any error. To work around this, I added a small web-only helper that lets the library complete the flow. It's not a second implementation: the library still owns the entire auth flow, and we simply receive the result through a different channel. It works reliably now across several local runs. The helper does lean on library internals that could change in a future version, so the unit tests reproduce the original hang, meaning a version bump that breaks this fails the suite instead of quietly hanging the flow.
For anyone interested in the details: under normal circumstances, the popup sends the result back via
postMessageusingwindow.opener. Somewhere in Cloudflare's redirect chain, the popup loses itswindow.opener, so the message has nowhere to go. Fortunately, just before sending thepostMessage,expo-web-browseralso stores the callback URL inlocalStorage, which remains accessible regardless of what happens towindow.opener. The main window now listens for that value instead, while an orphaned popup closes itself after writing it. The workaround is about 100 lines of code and depends on a couple oflocalStoragekey names used byexpo-web-browser@56.0.5.mateuuszzzzz commentedon Jul 30, 2026
Regarding this popup issue, I wonder if popup is preferred/required option here. If not, we could redirect to CF in current tab (full-page redirect) and this would probably allow us to overcome this
expo-web-browserissue entirely. cc: @iwizniamateuuszzzzz commentedon Aug 6, 2026
Update:
I implemented full-page redirect today, it works and tests well, I pushed it to our fork: https://github.com/software-mansion-labs/expensify-app-fork/tree/poc/qa-env/web.
I also discovered that we only perform SAML sign-outs via
expo-web-browser. Sign-in uses full-page redirect as well so I would stick to this approach for CF ZeroTrust. I'll update design doc accordingly. From other things, we're starting "proper" implementation phase with @JakubKorytko. I'll be working on mobile side. He'll be working on webmateuuszzzzz commentedon Aug 12, 2026
Update:
I created a draft PR today with QA auth utils that we need to build authentication flow on NewDot web and mobile
96 remaining items
JakubKorytko commentedon Oct 13, 2026
Nothing from me, I think @sharabai would have one though!
mallenexpensify commentedon Oct 14, 2026
Please comment and tag me if/when payment is due, thx
sharabai commentedon Oct 14, 2026
Quick QA update: I'm still working through these problems with QA's Cloudflare sign-in:
Once I've figured these out I'll probably leave a few comments on the design doc, but I'm still working out how best to solve them.
huult commentedon Oct 15, 2026
Thanks for the update!
melvin-bot commentedon Oct 20, 2026
@huult Eep! 4 days overdue now. Issues have feelings too...
huult commentedon Oct 21, 2026
Not overdue. @sharabai, do we have any new updates?
sharabai commentedon Oct 21, 2026
Quick update! I've stopped working on the feature branch for now.
While going through the problems from my last update, I kept running into cases the design doc doesn't cover. There were too many to just figure out as I go, and a lot of them need an actual decision. So I started my own design doc for them. It's still a draft and I'm adding to it.
It builds on the feature branch, which follows the original design doc. The PRs that already merged were mostly prep work: refactoring, tooling, and checking that the connection to Cloudflare works. The branch doesn't handle a lot of edge cases yet, especially around errors. So far the draft covers:
huult commentedon Oct 22, 2026
Thanks for the update, and for taking the time to write the design doc for the edge cases.
huult commentedon Oct 22, 2026
I think this PR should have a weekly label since work is ongoing. If you disagree, we can switch it back to daily and update it accordingly, @iwiznia.