Fix relationship data issue

[calebbourg]

Description

Implement role-based access control for coaching relationships to ensure users can only view relationships they are authorized to see based on
their role permissions.

Changes

• Add find_by_user_and_organization_with_user_names function in entity_api layer to filter coaching relationships by user
• Implement find_by_organization_for_user_with_user_names in domain layer with role-based filtering logic:
  • SuperAdmins: see all relationships in any organization
  • Org Admins: see all relationships in their organization
  • Regular users: see only relationships where they are coach or coachee
• Update coaching relationships index endpoint to use the new role-aware function
• Add Clone derive to CoachingRelationshipWithUserNames for test extensibility
• Add mock feature to domain Cargo.toml for future testing support

Testing Strategy

Manual tested by:

1. Creating users with different roles (SuperAdmin, Admin, regular user)
2. Creating coaching relationships between users in the same and different organizations
3. Querying the coaching relationships endpoint with each user and verifying they only see authorized relationships

[jhodapp]

Got a few recommendations for improving the security and performance of this, otherwise looking great. Thanks!

[jhodapp]

From a correctness and security perspective, I think it makes sense to check to make sure that this user is first a member of the provided organization before doing any of the other checks.

Here's Claude's recommendation:

Attack Scenario:

1. User A is authenticated but has no relationship with Organization X
2. User A calls GET /organizations/{org_x_id}/coaching_relationships
3. The function falls through to find_by_user_and_organization_with_user_names() (line 70)
4. This returns an empty list (not an error), which leaks that Organization X exists

Current Flow (domain/src/coaching_relationship.rs:30-73):

pub async fn find_by_organization_for_user_with_user_names(
    db: &DatabaseConnection,
    user_id: crate::Id,
    organization_id: crate::Id,
) -> Result<Vec<CoachingRelationshipWithUserNames>, Error> {
    // Check admin roles... ✓
    let is_super_admin = ...;
    let is_org_admin = ...;

    // ⚠️ MISSING: Verify user belongs to this organization!

    if is_super_admin || is_org_admin {
        find_by_organization_with_user_names(db, organization_id).await?
    } else {
        // Returns empty vec if user has no relationships - information leak
        find_by_user_and_organization_with_user_names(db, user_id, organization_id).await?
    }
}

Recommendation: Add organization membership verification:

// Add before the admin checks
let is_organization_member = check_user_organization_membership(db, user_id, organization_id).await?;
if !is_organization_member && !is_super_admin {
    return Err(Error {
        source: None,
        error_kind: DomainErrorKind::Authorization(AuthorizationErrorKind::Forbidden),
    });
}

[calebbourg]

This actually was already handled in our authorization checks but I updated them to use the newer pattern and directory structure 3e0055a

[jhodapp]

Time-of-Check to Time-of-Use vulnerability:

// TIME OF CHECK: Query role
let is_super_admin = user_roles::Entity::find()...one(db).await?;
let is_org_admin = user_roles::Entity::find()...one(db).await?;

// GAP: Role could be revoked here by another transaction

// TIME OF USE: Query data based on stale role check
let coaching_relationships = if is_super_admin || is_org_admin {
    find_by_organization_with_user_names(db, organization_id).await?
} else {
    find_by_user_and_organization_with_user_names(db, user_id, organization_id).await?
};

Attack Scenario:

1. Admin requests coaching relationships
2. Role check passes (line 36-63)
3. Another admin revokes their role
4. Data query executes with now-invalid permissions (line 65-71)

Mitigation:

• Database Transaction: Wrap the entire operation in a serializable transaction

[calebbourg]

Added! bbe8913

[jhodapp]

Looks great, thanks for the fix!