Open RihanArfan opened 3 months ago
Should it be something that we document instead?
The issue with my workaround is that if anyone knows the hostname of the application, they can bypass Access as the rule allows everyone to access /api/_hub
endpoints. If the secret or user token is compromised, an attacker could then read/write the production database. Cloudflare Access would prohibit this as they haven't authenticated with corporate SSO.
Even if the rule limited to NuxtHub IPs, I believe NuxtHub runs on Cloudflare so a malicious user can just use a Worker to make requests from Cloudflare IPs too. I'm happy to PR documention for this workaround in August once I finish uni. However if option 1 or 2 could be considered it's be amazing so Access can fully protect the application 100% from any unauthenticated/public request without breaking NuxtHub dashboard features.
Cloudflare Access also affects npm run dev --remote
too, as requests won't be through the authenticated Access browser session. I think adding headers to proxyHubX()'s ofetch from a hook/environment variables/runtime config would be pretty simple (and something I can PR later possibly if you'd like).
Looking forward to see your PRs :)
Describe the bug When using Cloudflare Access to protect the site, it's not possible to use the database viewer/integrated Drizzle Studio, as it accesses using a proxied request, so any authenticated Cloudflare Access session for the user in the browser doesn't apply.
Steps to reproduce Enable Cloudflare Access for the Cloudflare Pages site.
Workarounds Adding a bypass for everyone which applies to
/api/_hub
Ideal fix