add questionnaire to onboarding#28119
Conversation
6ded613 to
6a4dbd0
Compare
d3fe3c7 to
0301db7
Compare
6a4dbd0 to
1c7225e
Compare
0301db7 to
36be9c3
Compare
1c7225e to
0147c30
Compare
36be9c3 to
4b76789
Compare
33527b4 to
03ea22f
Compare
2bf7b46 to
763b140
Compare
2550b52 to
cbd398f
Compare
cbd398f to
4135e64
Compare
75ea1f5 to
b803712
Compare
ae75e1c to
2c40f65
Compare
2c40f65 to
d446b9f
Compare
0915391 to
37ebc1d
Compare
There was a problem hiding this comment.
I would love thoughts on this change. Are we still secure if leveraging WithAuthCookieAndCSRF?
We set a bearer token on redirect to /web at the end of the registration. Until then, there is no bearer token to check.
There was a problem hiding this comment.
tbh, i'm not sure either... i would love to know a definite answer though, because i have questions, like why not all protected endpoints use that too then? (perhaps these endpoints where it's used, the consequence aren't as high?) and also why didn't we pass the access token instead of the csrf token in the form? (this form is located where user was already authenticated)
but i took a look at WithAuthCookieAndCSRF and it's intended for non-ajax request (forms) so I would generally stay away from it.
i wonder if we can use local storage to temporarily store the user preference, then on init, we can update user preference there, and then delete that storage key?
There was a problem hiding this comment.
Follow up PR
f913506 to
427074e
Compare
There was a problem hiding this comment.
shoot... idk how strict we want to be with enterprise endpoints not being in enterprise config
if you already got an ok from someone to do it like this, i'm okay with it. Otherwise, we might need to create an enterprise version of Welcome and move questionaire comps into enterprise (this would've been the direction I would've taken).
though tbh, this feature is mostly a data collection for us, so i'm inclined to say it's okay to be in OS? but i'd get a third opinion
There was a problem hiding this comment.
There is a plan to add this survey to the OSS onboarding flow as well; we wouldn't submit OSS responses to Sales Center... but that's why I built it out in Teleport vs. Teleport.e. We could duplicate this down to E, and have essentially duplicate onboarding flows with the exception of one making an additional call... but I don't like the maintenance of keeping them in sync.
I'm thinking about this; I don't have a solid answer yet. I'm going to brainstorm a bit more.
There was a problem hiding this comment.
tbh, i'm not sure either... i would love to know a definite answer though, because i have questions, like why not all protected endpoints use that too then? (perhaps these endpoints where it's used, the consequence aren't as high?) and also why didn't we pass the access token instead of the csrf token in the form? (this form is located where user was already authenticated)
but i took a look at WithAuthCookieAndCSRF and it's intended for non-ajax request (forms) so I would generally stay away from it.
i wonder if we can use local storage to temporarily store the user preference, then on init, we can update user preference there, and then delete that storage key?
427074e to
d3a55f3
Compare
- Adds user context wrapper to the Welcome flow in order to update preferences - Sets selected resources on user preferences
820b79b to
daf802b
Compare
|
Closing this PR, moving survey to E. |
This PR adds the questionnaire survey to the onboarding flow. On save, the full survey results are sent to Sales Center, Resources are saved to cluster state (user preferences) and a Posthog event is triggered.
This does not include:
blocked by: https://github.com/gravitational/teleport.e/pull/1713
supports: https://github.com/gravitational/cloud/issues/4802