Using Next.js as an example, but I believe this problem is wider spread.
When you run through the process you're asked a series of questions. This helps you get things setup (in my experience) pretty well. Two things however that it does do not make it the easiest to succeed when going to production:
1) There is no explicit or implicit environmental awareness for disabling Sentry in development. This was intentional to make it easy for people to verify its setup correctly, but is not desired behavior outside of that setup test.
2) There is an error trigger mechanism in some situations, which creates a DoS or otherwise undesirable abuse vector in production environments.
From an outcomes point of view, there's a number of ways it can be solved, but what we desire is:
(1) Users understand - and have low friction - to disable Sentry in development environments outside unless its explicitly desired (its not for most people, and provides a worse experience, especially out of the box)
(2) Sentry does not expose any attack vectors in production that could otherwise be avoided. That means any kind of endpoint which is specifically designed for testing or debug should not be enabled in a production stack.
(1) likely exists outside of the Wizard, as most of our docs no longer talk about dev vs production anywhere (as far as I can tell), and these days many apps are not configured via env variables (thus less obvious how you should or even can disable it). I believe Wizard makes this worse as users are even less hands on, and they're assuming things are "correct" out of the box, vs if they had gone through the instructions themselves.
(2) I did not step through to verify what our approach is to this everywhere, but its something we should be aware of and I know it hasn't been top of mind in the past. We likely need to adjust some of the implementations of this and/or make it very clear that folks should remove it before shipping to production.
Using Next.js as an example, but I believe this problem is wider spread.
When you run through the process you're asked a series of questions. This helps you get things setup (in my experience) pretty well. Two things however that it does do not make it the easiest to succeed when going to production:
1) There is no explicit or implicit environmental awareness for disabling Sentry in development. This was intentional to make it easy for people to verify its setup correctly, but is not desired behavior outside of that setup test.
2) There is an error trigger mechanism in some situations, which creates a DoS or otherwise undesirable abuse vector in production environments.
From an outcomes point of view, there's a number of ways it can be solved, but what we desire is:
(1) Users understand - and have low friction - to disable Sentry in development environments outside unless its explicitly desired (its not for most people, and provides a worse experience, especially out of the box)
(2) Sentry does not expose any attack vectors in production that could otherwise be avoided. That means any kind of endpoint which is specifically designed for testing or debug should not be enabled in a production stack.
(1) likely exists outside of the Wizard, as most of our docs no longer talk about dev vs production anywhere (as far as I can tell), and these days many apps are not configured via env variables (thus less obvious how you should or even can disable it). I believe Wizard makes this worse as users are even less hands on, and they're assuming things are "correct" out of the box, vs if they had gone through the instructions themselves.
(2) I did not step through to verify what our approach is to this everywhere, but its something we should be aware of and I know it hasn't been top of mind in the past. We likely need to adjust some of the implementations of this and/or make it very clear that folks should remove it before shipping to production.