32 results found
-
26 votes
-
23 votes
-
16 votes
-
Manage minInstances setting of pinned functions of previous releases
Pinned functions of previous releases keep their minInstances setting. E.g. after deploying 10 times with a minInstances setting of 1, there will be 10 idling instances but only the newest revision handles all the traffic. Yet the remaining 9 instances' idle time is billed as well because the function is still addressable through the revision tag.
This also affects the maxInstances setting: With a maxInstances setting of 10, the newest Cloud Run revision which handles 100% of the traffic won't be able to scale anymore.
As far as I know, the only way to handle this right now is to…
5 votes -
13 votes
-
Password-protected preview domains
Squarespace has a featured for "site-wide password protection" which is useful for staging unlaunched websites for stakeholders to review. This would help guard against any potential leaks.
Figma also has a feature similar to this.
We currently have to create a custom express.js server with an authentication middleware, but this is undesirable for several reasons:
- We'd have to re-create all of firebase hosting's serving features (i18n fallbacks, redirects, pretty urls, etc.)
- We can't easily test endpoints that are proxied to Functions/GCR
11 votes -
Pass all cookies to Cloud Functions or Cloud Run
Right now only a _session Cookie is passed.
https://firebase.google.com/docs/hosting/manage-cache#usingcookies4 votes -
11 votes
-
CDN Invalidation API
Add an official API to support cache invalidation via resource URL, header, or tag.
The rate limit to such an API should be high enough to support what people already do with the non-official API to invalidate by URL.
9 votes -
Allow URLs to be accessible fully, or by invitation, or by password protection, like Notion and Figma
Allow natively what we can do in Notion / Figma (sharing a prototype), by sharing a page with the followings options:
1/ allow a page to be fully accessible (that's already possible, so the default)
2/ allow a page to be viewed only if we provide another User a link.
3/ allow a page to be viewed if 2/ + password protected9 votes -
Hosting CDN cache stale-while-revalidate
Time-to-first-byte from Firebase Functions is usually slow (more than 500ms) even without cold start, sometimes (with cold starts) TTFB becomes absolutely unacceptable for projects where performance is important. SSRed HTML is also not Brotli compressed as static files.
This is a really big problem to deploy SSR web apps to Firebase IMO, and cache SWR at the CDN layer (edge) would solve it perfectly.3 votes -
8 votes
-
Restrict Unauthenticated PURGE requests
At the moment Hosting is using Varnish cache which developers do not have access so they can't configure it, this leaves a small window for people to continuously Purge the page and increase the developer's usage
6 votes -
6 votes
-
The ability to turn on/off the decoding of encoded data url in firebase.json
When I hosted a frontend client (React JS) and backend (NodeJS) server in hosting and functions combination, there were some scenarios where in I needed to send data (to server) which contained slash (so encoded them).
This was where the problem rose, the encoded component was automatically decoded by the firebase hosting itself and sent the wrong url to the underlying server.
Therefore firebase should give us the ability to turn on/off the decoding of encoded data url in firebase.json
my current firebase.json file -
{
"functions": [
{
"source": "functions",
"codebase": "default",
"ignore": [
"nodemodules",
".git",
"firebase-debug.log",
"firebase-debug.…2 votes -
Get rid of the egress data transfer fee for Firebase Hosting
All is described in the title. I no longer see any benefits to using Firebase Hosting when you have competition like Cloudflare pages that charges zero for egress traffic.
By reworking Firebase hosting egress fees, it could attract more users looking for a hosting solution and then convert them to a paid product linked with hosting like Firestore, Functions, etc.
6 votes -
Support yarn and/or pnpm for frameworks
Currently frameworks only used npm
This can cause issues if using yarn or pnpm, and npm does not read the lockfile and you can end up with different versions of dependencies in production
Deployments with frameworks should detect the package manager used
1 vote -
5 votes
-
Support deployment of Nuxt 3 projects to Hosting
Currently, support for Web Frameworks (Beta) only supports Next.js and Angular: https://firebase.google.com/docs/hosting/frameworks/frameworks-overview. Nuxt is labeled as 'Soon' at https://github.com/FirebaseExtended/firebase-framework-tools
I just wanted to cast my vote for Nuxt 3 support and try out the new portal :) Thanks!
3 votes -
Trusted headers for client IP address via Firebase Hosting
Context: from a backend running on Cloud Run/Cloud Functions, how to determine client IP address, when you need to TRUST it for IP-address based access restrictions.
You can normally find the real client IP as the first entry in the X-Forwarded-For header, but you cannot trust it.
If you are using Cloud Run (or Cloud Functions gen 2), then as far as I can tell the Cloud Run orchestrator always sits as a proxy in front of your container. This means you can trust the last entry in X-Forwarded-For as this is the client IP seen by Cloud Run itself.…
2 votes
- Don't see your idea?