[TT-14359] fix nested scopes for identity base field #7522

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

andrei-tyk merged 7 commits into master from TT-14359-fix-nested-scopes-for-identity-base-field

Nov 10, 2025

Merged

[TT-14359] fix nested scopes for identity base field #7522

Merge branch 'master' into TT-14359-fix-nested-scopes-for-identity-ba…

probelabs / Visor: quality failed Nov 10, 2025 in 6m 26s

🚨 Check Failed

quality check failed because fail_if condition was met.

Details

📊 Summary

Total Issues: 3
Error Issues: 2
Warning Issues: 1

🔍 Failure Condition Results

❌ Failed Conditions

global_fail_if: Global failure condition met
- ⚠️ Severity: Error

🐛 Issues by Category

🧠 Logic (2)

❌ gateway/mw_jwt.go:1525 - The logic to find a claim's value is duplicated between the getClaimValue function and the getUserIDFromClaim function. getClaimValue returns false for both a non-existent claim and a claim that exists but has an empty string value. This forces getUserIDFromClaim to re-implement both literal and nested lookups to distinguish between these two cases, as an empty value should result in an error while a non-existent value should trigger a fallback. This duplication makes the code inefficient (e.g., nestedMapLookup may be called twice for the same claim) and harder to maintain.
❌ system:0 - Global failure condition met

🎨 Style (1)

⚠️ gateway/mw_jwt.go:388 - In a log message, an em dash (—) was replaced with a question mark (?), which makes the message's intent slightly less clear. This appears to be an unintentional typo. The same change is present on line 424.

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>

Annotations

Check failure on line 1554 in gateway/mw_jwt.go

probelabs / Visor: quality

logic Issue

The logic to find a claim's value is duplicated between the `getClaimValue` function and the `getUserIDFromClaim` function. `getClaimValue` returns `false` for both a non-existent claim and a claim that exists but has an empty string value. This forces `getUserIDFromClaim` to re-implement both literal and nested lookups to distinguish between these two cases, as an empty value should result in an error while a non-existent value should trigger a fallback. This duplication makes the code inefficient (e.g., `nestedMapLookup` may be called twice for the same claim) and harder to maintain.

Raw output


            Modify `getClaimValue` to return the found value as `interface{}` along with a boolean indicating if it was found. This would centralize the lookup logic. The calling functions would then be responsible for type assertion and value validation (e.g., checking for empty strings). This would eliminate the need for `getUserIDFromClaim` to perform its own redundant lookups.

Check warning on line 388 in gateway/mw_jwt.go

probelabs / Visor: quality

style Issue

In a log message, an em dash (`—`) was replaced with a question mark (`?`), which makes the message's intent slightly less clear. This appears to be an unintentional typo. The same change is present on line 424.

Raw output


            It is recommended to revert the `?` to the original `—` or rephrase the message to improve clarity, for example: `...for APIID %s, URL %s, ignoring`.

View more details on probelabs