35 results found
-
38 votes
-
25 votes
-
17 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
15 votes -
15 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.
12 votes -
12 votes
-
12 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 protected10 votes -
Secure Transport Layer Implementation
The "Secure Transport Layer Implementation" idea centers around fortifying the application's transport layer to mitigate vulnerabilities, particularly the risk of insufficient protection against attacks like POODLE. This vulnerability exposes the application to potential exploits, compromising the confidentiality and integrity of data exchanged between the application and its users.
Insufficient transport layer protection opens the door to various security threats, including man-in-the-middle attacks, data interception, injection of malicious content, and communication redirection. These threats undermine the trustworthiness of the application and jeopardize user data security.
To address this vulnerability effectively, it's imperative to reinforce the application's transport layer security by implementing…
8 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.
7 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
-
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 -
5 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 -
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.4 votes -
4 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.…3 votes -
X-User-Country header when proxying to Google Cloud Run
App Engine and Cloud Functions send X-AppEngine-Country to app servers, which is useful for serving regional content to users.
Google Cloud Run doesn't receive the same headers. GCR can receive this header through load balancer custom headers (https://cloud.google.com/load-balancing/docs/https/custom-headers), but it'd be great if it were supported through Firebase Hosting directly without any extra configurations.
3 votes
- Don't see your idea?