Generate Org Auth Token for Sentry Wizard

[Lms24]

Right now, in the wizard we're still generating the old, user-scoped auth tokens. We recently introduced Org-scoped auth tokens which should be preferred over user-based tokens whenever possible. We therefore want to create them in the wizard when selecting a project. Unfortunately, due to the nature of the current project selection flow, this brings along some challenges:

Problem

• The SetupWizardView in the Sentry backend currently obtains one list of projects across all active orgs of a user.
  • While doing so, it also obtains or generates a new token for the logged-in user
  • Since we don't know which org the user is going to select a project from in the wizard later, for which org should we generate a token?

Solution

We move the project selection step from the CLI to the browser UI. Instead of only logging in in the browser, users will also select their project afterwards.

More specifically, we modify the SetupWizard React component that's loaded by the Django template to tell users to return to the wizard. If there's more than one org and project assigned to the user, the user needs to select their project inside the browser. After the selection, we make another request to the SetupWizardView which creates a new org token and updates the cache. During this entire time, the CLI (wizard) will wait until the project is selected and the backend created the corresponding org auth token. Once this is done, the CLI receives back the selected project data and token and it directly continues with the setup.

Advantages

• It solves the chicken/egg problem of org selection and org auth token creation.
• For users with many orgs, this will significantly improve the UX of selecting a project. Right now, scrolling through the list of projects in the CLI is less than ideal.

Disadvantages

• Users with >1 org or project need to do one step more in the browser
• We need to maintain the old flow (i.e. add this change as a new endpoint/view/react component) to maintain backwards-compatibility with older wizard versions.

Alternatives Considered

• Just generate a token for each of the user's orgs
  • Potentially blows up the number of tokens. Think about Sentry employees who are part of a lot of orgs trying out the wizard. Each time they authenticate themselves, a new token would be created for each org.
• Stay with the old user-based token generation
  • This would mean we'd still end up with user-based tokens in a substantial amount of projects, especially given that we're pushing the source maps wizard.

This boils down to the following tasks:

Tasks

Beta Give feedback

1. Design: Org/Project Selection for Wizard sentry#53045
   +0
   
2. Create Org token for users with one only organization #394
   +0
   
3. Create new View and Endpoint and react component for the reworked flow due to backwards compatibility
4. [sentry-backend] Make sure the new SetupWizardView passes the necessary data to the Django template which passes it to the react component
5. [sentry-frontend] Add project selection to the new SetupWizard React component and send a PUT request back to the view with the selected project
6. [sentry-backend] Add PUT handler to the new SetupWizardView that takes the selected org id, creates a new org token and updates the cache
7. [sentry-backend] Adjust the new setup_wizard API endpoint to only return data from the cache if the project is selected and the org token is available
8. [sentry-wizard] Adjust the wizard flow to no longer display the projects list but handle the returned selected project and token

org auth tokens epic: getsentry/team-sdks#6
ref: getsentry/team-sdks#16

[smeubank]

discussion with @danielkhan

when coming from product (onboarding wizard & issues & even docs if logged in) we do know the org and project. So is this necessary?

state:
you're just running a command in terminal. It directs the user to login from terminal today.

solutions

1. wizard login flow includes UI for org and project selection (the described solution above)
2. wizard command includes options for org and project slugs (SENTRY_ORG & SENTRY_PROJECT)
   a. project wizard and issue UI would need to include this dynamically in snippet to have a nice UX users would actually use
   b. if org and project included then hopefully the wizard could create the org auth token without further prompt from the user but the user is still not "logged in" from the wizard's POV so maybe no auth to do create
3. wizard has option for SENTRY_AUTH_TOKEN which could be generate upon some button click in UI and included in copy paste in a secure manner to be run in terminal

[Lms24]

when coming from product (onboarding wizard & issues & even docs if logged in) we do know the org and project. So is this necessary?

Yes, we need to link the current wizard "session" to the Sentry backend to get any kind of data. To get this data, users need to be authenticated, which they do by logging in in the browser. If they're already previously logged in, they of course don't have to enter their credentials again but they're just forwarded. Regardless, the important part is that we authenticate and have the necessary permissions to get the data.

Also, we don't know for certain what users did before they started the wizard and much less if the project they want to configure with the wizard is the one that they had open when they saw the command. Also, there's no guarantee that they're logged in when viewing docs.

state:
you're just running a command in terminal. It directs the user to login from terminal today.

Users log in via the browser today already. The wizard, by design, holds no authentication/credential data. The only thing that connects the wizard session to the authentication that happened in the browser is a hash which is used as a cache key. The wizard polls an endpoint with this key until it gets its data (right now a list of projects) and continues from their.

2. wizard command includes options for org and project slugs (SENTRY_ORG & SENTRY_PROJECT)

We can add this as an optional arg but I'd argue that making this required significantly decreases ease of use.

3. wizard has option for SENTRY_AUTH_TOKEN which could be generate upon some button click in UI and included in copy paste in a secure manner to be run in terminal

I might miss some context around this suggestion but how is this different from 2? Requiring users to already create an auth token before starting the wizard again increases friction.

I think what's important to consider is that right now, today, users do not need to worry at all about their auth token when they use the wizard. However, they experience friction when selecting their project if they have more than a small number of projects. We should not degrade the UX just to get org tokens working in the wizard. However, doing project selection in the UI would increase usability for those with a higher number of projects.

[smeubank]

We can add this as an optional arg but I'd argue that making this required significantly decreases ease of use.

everything suggested would be optional. It should be thought of more like if not provided then normal flow with UI logins and selections, but IF provided then maybe the user can skip some steps

[ale-cota]

We can add this as an optional arg but I'd argue that making this required significantly decreases ease of use.
@Lms24 I think it won't look pretty, but the idea was that when they are starting the wizard flow after being prompted in the product, we already have that context there.

For example: I've just signed up for Sentry and created a React project. In the product we already know the org and project at that point so we could include these args in the command itself that they copy and paste. Similarly if the user is on the issues details page. The command will be pretty darn long 🙈 but if they just click a button to copy theoretically it makes no difference.

If we're able to do this, then theoretically we eliminate the step of them having to choose any org or project again, so it makes it slightly simpler. We still need the UI like you suggested for cases where customers just use the basic command.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[Lms24]

omg this bot is so annoying

[Lms24]

Worth noting (we need to sketch this out in more detail): With the Hybrid Cloud region split, this task now has higher priority. We should reconsider the requirements though because we also need to paginate results. So even just within one project, we shouldn't load 1k projects at once because this could cause timeouts.

[Lms24]

I guess pagination is easier in a browser UI than CLI but I'm still a bit unsure about the whole "move things to the UI" idea. wondering what users would prefer:

1. spend more time in the browser (as outlined in this issue)
2. take more steps in the CLI (i.e. 1. select org 2. select project; how would we paginate this properly... we can't just update the prompt and append results - this is tricky in CLI land)