Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wizard should set users up for production success #668

Open
dcramer opened this issue Sep 9, 2024 · 0 comments
Open

Wizard should set users up for production success #668

dcramer opened this issue Sep 9, 2024 · 0 comments

Comments

@dcramer
Copy link
Member

dcramer commented Sep 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant