Browse Source
The TestPresignedURLIAMValidation was failing because the presigned URL validation was hardcoding the principal ARN as 'PresignedUser' instead of extracting the actual role from the JWT session token. ### Problem: - Test used session token from S3ReadOnlyRole - ValidatePresignedURLWithIAM hardcoded principal as PresignedUser - Authorization checked wrong role permissions - PUT operation incorrectly succeeded instead of being denied ### Solution: - Extract role and session information from JWT token claims - Use parseJWTToken() to get 'role' and 'snam' claims - Build correct principal ARN from token data - Use 'principal' claim directly if available, fallback to constructed ARN ### Test Results: ✅ TestPresignedURLIAMValidation: All 4 test cases now pass ✅ GET with read permissions: ALLOWED (correct) ✅ PUT with read-only permissions: DENIED (correct - was failing before) ✅ GET without session token: Falls back to standard auth ✅ Invalid session token: Correctly rejected ### Technical Details: - Principal now correctly shows: arn:seaweed:sts::assumed-role/S3ReadOnlyRole/presigned-test-session - Authorization logic now validates against actual assumed role - Maintains compatibility with existing presigned URL generation tests - All 20+ presigned URL tests continue to pass This ensures presigned URLs respect the actual IAM role permissions from the session token, providing proper security enforcement.pull/7160/head
1 changed files with 32 additions and 3 deletions
Loading…
Reference in new issue