Skip to content

Conversation

@lebaudantoine
Copy link
Collaborator

When declaring scopes with our OIDC provider, they require us to prefix each scope with our application name. This is to prevent reserving generic scopes like rooms:list for only our app, as they manage a large federation.

I’m proposing a workaround where, if a resource server prefix is detected in the scope, it’s stripped out. This solution is simple and sufficient in my opinion.

Since the scopes are defined in the database, I don’t want to update them directly. Additionally, each self-hosted instance may have a different application name, so the prefix should be configurable via a Django setting.

@lebaudantoine
Copy link
Collaborator Author

@coderabbitai full review

@coderabbitai
Copy link

coderabbitai bot commented Nov 24, 2025

✅ Actions performed

Full review triggered.

When declaring scopes with our OIDC provider, they require us to prefix
each scope with our application name. This is to prevent reserving generic
scopes like rooms:list for only our app, as they manage a large federation.

I’m proposing a workaround where, if a resource server prefix is detected in
the scope, it’s stripped out. This solution is simple and sufficient
in my opinion.

Since the scopes are defined in the database, I don’t want to update
them directly. Additionally, each self-hosted instance may have a different
application name, so the prefix should be configurable via a Django setting.
@coderabbitai
Copy link

coderabbitai bot commented Nov 24, 2025

Caution

Review failed

Failed to post review comments

Walkthrough

The changes implement support for optional scope prefix stripping in OIDC token validation. A new configuration setting OIDC_RS_SCOPES_PREFIX is introduced in the settings module with a default value of None. The permission validation logic is updated to normalize token scopes by conditionally removing the configured prefix from each scope before comparing against required scopes. Corresponding test cases are updated to use prefixed scope values to verify the normalization behavior.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Logic changes in permissions.py require understanding the scope normalization flow and how it handles both list and space-separated string formats
  • Scope stripping logic needs verification for edge cases (missing prefix, None values, empty scopes)
  • Changes span multiple files (permissions, tests, and settings) with coordinated scope handling
  • New configuration setting integration with environment variables

Areas requiring extra attention:

  • The conditional prefix stripping logic in has_permission method to ensure it correctly handles all scope formats
  • Edge case handling when OIDC_RS_SCOPES_PREFIX is None or empty
  • Test coverage completeness for scenarios where prefixed and unprefixed scopes may coexist

Pre-merge checks

✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically describes the main change: adding support for prefixing resource server scopes in the OIDC configuration.
Description check ✅ Passed The description is directly related to the changeset, explaining the business context, motivation, and implementation approach for handling OIDC scope prefixes.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants