Support an array of authorized paths

[kixelated]

My use case is that a user should be able to get announcements for their favorite channels, not the entire world. This required a BREAKING auth change because the existing "sub" field in the token actually has meaning in JWT, and needs to be a string.

I also took another stab at Path. It's nicer now... except lifetimes can be a pain. I couldn't figure out how to get serde deserialize because of lifetimes so I'm using strings for now.

[claude]

Claude finished @kixelated's task —— View job

---

Code Review Complete 👍

After reviewing this PR for bugs and security issues, I found one critical security issue that should be addressed:

🚨 Critical Issue: Panic-based DoS vulnerability

Location: rs/moq-relay/src/auth.rs:91-93

let suffix = root
    .strip_prefix(&claims.root)
    .context("path does not match the root")?;

Problem: The code calls strip_prefix() but expects it to return None when there's no match. However, strip_prefix() can panic in some edge cases with malformed paths, potentially causing a DoS attack.

Impact: An attacker could craft specific URL paths that cause the relay to panic and crash.

Recommendation: Add proper validation before calling strip_prefix() or use a safer alternative that handles all edge cases gracefully.

---

✅ Positive Security Observations:

• JWT implementation correctly avoids using "sub" field (per JWT standards)
• Proper token expiration validation in place
• Authentication logic properly scoped to authorized paths
• Good separation between cluster and non-cluster permissions
• Path normalization in the new Path implementation prevents common traversal issues

✅ Code Quality:

• Breaking changes are well-documented and necessary for JWT compliance
• Comprehensive test coverage for the new authentication logic
• The new Path implementation with lifetime handling is a solid improvement

Overall Assessment: Good security-focused refactor with one critical fix needed. The architecture changes properly implement the multi-path authorization requirement while maintaining security boundaries.

[claude]

Claude finished @kixelated's task —— View job

---

Code Review Complete 👍

Review Tasks

• Examine JWT token claims changes for security issues
• Review new Path implementation for potential vulnerabilities
• Check authentication/authorization logic in relay
• Look for common security patterns and potential DoS vectors
• Review overall code quality and potential bugs

---

After a thorough security review of this PR, I found no critical security issues. Here's my assessment:

✅ Security Assessment: GOOD

JWT Implementation Changes:

• ✅ Correctly avoids using "sub" field per JWT standards (line 55 in claims.rs)
• ✅ Proper token expiration validation is in place
• ✅ Authentication logic properly scoped to authorized paths
• ✅ Good separation between cluster and non-cluster permissions

Path Implementation Security:

• ✅ The new Path implementation properly handles normalization and prevents common path traversal issues
• ✅ strip_prefix() method safely returns Option<Path> - no panic risk as I initially thought
• ✅ Path trimming and multiple slash collapse prevents bypass attempts

Authentication Flow:

• ✅ Proper error handling in auth.rs:91-93 - the code correctly uses Option return from strip_prefix()
• ✅ No dangerous unwrap() calls in security-critical paths (connection.rs lines 38,48 are safe as they use validated tokens)

✅ Code Quality Observations:

Breaking Changes:

• Well-documented and necessary for JWT compliance
• The move from "sub" to proper array-based authorization is architecturally sound

Test Coverage:

• Comprehensive test coverage for new authentication logic
• Good edge case testing for path operations

Architecture:

• The new multi-path authorization properly implements the stated requirement
• Clean separation of concerns between authentication and authorization

Minor Notes:

• Some unwrap() calls in non-security paths (cluster.rs:155, web.rs:102) could be improved with better error handling, but pose no security risk
• The new Path implementation with lifetime handling is well-implemented despite the author's concerns about lifetimes

Overall Assessment: This is a solid security-focused refactor that improves JWT compliance while adding multi-path authorization capabilities. No security issues found.

---