feat(replays): guard API endpoints by granular replay access

[shellmayr]

Replaces #104452 because it was a PITA to rebase

• Implement the guarding of endpoints by granular permissions for replays, building on the data model established in feat(replay): add model to allow per-user access control for replays #104446
• Introduce base endpoint classes OrganizationReplayEndpoint and ProjectReplayEndpoint to centralize feature and permission checks for replay access, ensuring consistent enforcement across all replay endpoints.
• Updated all replay endpoints to use the new base classes and enforce granular permissions, returning appropriate HTTP status codes for unauthorized access.
• More information on the plan & product impact can be found here Research granular permissions for viewing Replays

Closes TET-1564

[linear]

TET-1564 Granular replay permissions - gate endpoints by permissions

[codecov]

Codecov Report

❌ Patch coverage is 99.09091% with 1 line in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...plays/endpoints/organization_replay_events_meta.py	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #104955      +/-   ##
===========================================
+ Coverage   80.43%    80.46%   +0.03%     
===========================================
  Files        9394      9410      +16     
  Lines      403509    404287     +778     
  Branches    25922     25922              
===========================================
+ Hits       324561    325321     +760     
- Misses      78508     78526      +18     
  Partials      440       440              

[cursor]

Bug: Missing session-replay feature flag check in deletion jobs endpoint

ProjectReplayDeletionJobsIndexEndpoint extends ProjectEndpoint and only checks has_replay_permission in its get and post methods, but does not verify the organizations:session-replay feature flag. In contrast, ProjectReplayDeletionJobDetailEndpoint in the same file correctly extends ProjectReplayEndpoint and uses check_replay_access, which includes both the feature flag and permission checks. This inconsistency allows users to access the deletion jobs index endpoint even when session-replay is not enabled for their organization.

 

[shellmayr]

I'll raise this one separately - don't want to change the original behaviour of the endpoint without checking with product first, maybe this is on purpose.

[constantinius]

The suggestion is not a blocker. LGTM

[JoshFerge]

This is a really useful feature that a lot of replays customers have been asking about for a long time, and is very exciting!

IMO we should start thinking about a more generalized RBAC approach than something one off for replays. l am concerned about the complexity and UX of a one-off permissions check. I'm also wondering if we could make it based on our existing permissions system scopes

[shellmayr]

@JoshFerge we had quite some discussions about different paths already, e.g. in this PR, and in these linear issues (one, two). The ask from product is very clearly a user-based permission model that is wholly separate existing role-based permissions model. I agree with you that a generalized approach for a more granular permission model is desirable, but this honestly is beyond the scope of this task.

I'd propose the following way forward:

1. We take it step-by-step, make this change with a restricted blast radius in replays, see how it works, and if it brings big complexity with it when shipped. This should also teach us a bit about the difficulties of this type of system, if we want to extend it.
2. Once there is taste for additional product surfaces to be guarded in similar ways, in my opinion we can quite easily migrate the current concept over to a more generalized one.

What do you think about this course of action?

If we want a larger, generalized initiative to introduce a new, widespread permissions project, I think that is a wholly different size of task from what we're trying to do here.

[JoshFerge]

@JoshFerge we had quite some discussions about different paths already, e.g. in this PR, and in these linear issues (one, two). The ask from product is very clearly a user-based permission model that is wholly separate existing role-based permissions model. I agree with you that a generalized approach for a more granular permission model is desirable, but this honestly is beyond the scope of this task.

I'd propose the following way forward:

1. We take it step-by-step, make this change with a restricted blast radius in replays, see how it works, and if it brings big complexity with it when shipped. This should also teach us a bit about the difficulties of this type of system, if we want to extend it.
2. Once there is taste for additional product surfaces to be guarded in similar ways, in my opinion we can quite easily migrate the current concept over to a more generalized one.

What do you think about this course of action?

If we want a larger, generalized initiative to introduce a new, widespread permissions project, I think that is a wholly different size of task from what we're trying to do here.

This approach makes sense. I do think it's worth trying to get ahead of these sorts of UX issues & complexity especially as we plan for the long term. removing my review.

clarification

[shellmayr]

100% agree and thanks for understanding! Since you seem to have a hunch here & just to inform us going forward, are there any particular UX issues you can see coming up that you'd like us to take a look at in the short term?

[JoshFerge]

100% agree and thanks for understanding! Since you seem to have a hunch here & just to inform us going forward, are there any particular UX issues you can see coming up that you'd like us to take a look at in the short term?

do we have designs for how users will be granted this permission?

[shellmayr]

@JoshFerge yes - there's a video of the flow in this PR - tldr is that org managers and owners can enable access by switching a boolean, and then they can edit a list of users who are able to access replays

[JoshFerge]

@JoshFerge yes - there's a video of the flow in this PR - tldr is that org managers and owners can enable access by switching a boolean, and then they can edit a list of users who are able to access replays

are we sure we don't want to make it available to be assigned by team? admins will have to go and add every new user to this list? if there are over a 100 members in an org i do not see how this would be manageable.

[shellmayr]

@JoshFerge I think we'll have some larger orgs try this and see if it's manageable. Generally, I agree with you that the whole flow around adding members to and removing members from teams already exists and it would be convenient to base it on that, but the approach so far from the product side is clearly user-based and not team-based. We'd like to wait for feedback when the first users try it, and adapt if and when issues come up.

(FYI @jas-kas)