39 results found
-
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…
12 votes -
dynamic robots.txt and favicon
Add capability to dynamically change robots.txt and favicon. The current behavior returns 404.
3 votes -
42 votes
-
Site Not Found
i have deployed and when i try to go on default site i see site not found
1 vote -
BlackList for Hosting
Please block access from this UserAgent.
"Bytespider; spider-feedback@bytedance.com"2 votes -
Allow a function to set the headers of a hosting endpoint dynamically
Right now there does not seem to be a way to dynamically set the headers of a hosting response using a function.
Among other things, this makes it impossible to use a nonce.
1 vote -
Full-stack preview channels
Hosting preview channels are great, and work well for client-side code, however for full-stack apps that require a server (either for SSR or API routes), the preview channel uses to the 'main' server as a backend. It would be great if the server side code also got deployed to a new firebase function and was managed alongside the hosting preview.
2 votes -
25 votes
-
18 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 -
14 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 -
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 -
13 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#usingcookies5 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 -
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 -
Firebase hosting timeout should be configurable
I am using cloud run to and firebase hosting to have a custom domain to access my application.
I know Firebase doc mentions :
Firebase Hosting is subject to a 60-second request timeout. If your app requires more than 60 seconds to run, you'll receive an HTTPS status code 504 (request timeout).But I need to increase this timeout, since my cloud run app has a function to process data and write to an excel that can take up to 3mn.
1 vote -
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
- Don't see your idea?