refactor: DATA-12840 Avoid passing auth poken as a part of request query params

[bc-rmalyavc]

What/Why?

• Avoid passing auth token through request query params
• Implement lazy loading for db in order to avoid establishing a new connection on every single request

We've previously migrated from the approach where we stored auth token in cookies to query params based. Because of the 3rd party cookies deprecation. Now passing the actual token as a part of query params is not safe, so we needed to come up with a more secure approach. Since we use NextResponse.redirect method in the load/route we can not pass it in headers or request body. So that the new flow is the following

1. Upon hitting the load route we still generate the auth token as we did before
2. Then we temporarily store it in firebase. Which in turn returns us a so called exchangeToken, by which we can retrieve the actual auth token. It has a short TTL (currently 2 minutes and may be reduced)
3. Then the NextResponse.redirect happens as usual though this time we append this temporary exchangeToken to the URL query parameters (it is the only way we can pass something to the next route)
4. This redirects us to the src/app/productDescription/[productId]/page.tsx page where we generate the actual form. Here we get the exchangeToken from query params and fetch the actual authToken from firebase. It can be retrieved only once and then immediately gets removed from firebase.
5. As a part of this page we render the Generator (and then Form) component. We pass the token into the component as an attribute (as we previously did)
6. Finally this component needs the token to actually generate descriptions by calling api/GenerateDescription route. Previously we passed the token here as a query param too. With this change we pass it in headers instead and get from headers on the API side.

Rollout/Rollback

Merge/revert

Testing

• Tested locally with ngrok
• Testing on preview env.

1. Pointed a draft app to preview env where the current changes are deployed
2. Uninstalled and installed the app back to verify that it's still working considering changes to db
3. Navigated to a product edit page and opened the app. Verified that the original request now doesn't contain auth token in the url, but only passes an exchange token
4. Clicked the Generate description button and verified that auth token is not passed as a part of request url, but is passed through a request header
5. All functionality still works without issues

Screen.Recording.2025-09-11.at.15.16.42.mov

After merge tested the same flow including uninstall/install on production. Confirmed that everything works as expected

@bigcommerce/team-data

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
ai-app-foundation	Ready	Preview	Comment	Oct 23, 2025 10:58am

[bc-rmalyavc]

Hey @bc-donfran,
Could you please take a look at this PR and tell me if this approach is ok from your perspective? As you can see we still have to pass a token as a part of query params, though now it's just a temporary one time exchange token that we use to access the real auth token. It can not be re-used and it's very short lived. Upon my research it's the best we can do in the current circumstances, and it should be secure enough. But please let me know if you have any concerns.
Thanks

[bc-donfran]

Hey @bc-rmalyavc! That should be fine!

[solofeed]

Given Google’s updated stance on not fully phasing out third‑party cookies, introducing an additional exchange-token load flow feels like unnecessary complexity.
Instead of layering a temporary token store and redirect indirection, we should revert PR #48 and restore a secure HttpOnly cookie. This keeps the auth token out of URLs, reduces Firestore load, and simplifies maintenance.

Reverting is cleaner than maintaining an exchange mechanism

Also, it makes sense to discuss with Keith overall view and strategy for that app. It feels like we would want to build better UX and more feature functionality

[solofeed]

References:
https://www.techspot.com/news/107649-google-abandons-plans-phase-out-third-party-cookies.html
https://www.forbes.com/sites/zakdoffman/2025/10/21/phased-out-google-confirms-bad-news-for-all-3-billion-chrome-users/

[solofeed]

Ok, it seems like reverting to third‑party cookies is risky: Safari and Firefox already block or partition them

Based on the BigCommerce guidance we are supposed to move on

Approving

[solofeed]

@bc-rmalyavc thanks for clarification