Skip to content

General

General

Categories

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

36 results found

  1. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. 40 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. 25 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Please block access from this UserAgent.
    "Bytespider; spider-feedback@bytedance.com"

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. 18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. 15 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. 13 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. 13 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. 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 protected

    10 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. 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

    7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. 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

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Hosting  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
← Previous 1
  • Don't see your idea?