fix: respect disabled state for resources

[vikrantgravitee]

Issue

https://gravitee.atlassian.net/browse/APIM-11119

Description

Disabled OAuth2 resources now properly block token validation. Previously, disabling a OAuth2 resource had no effect, allowing OAuth2 plans to continue validating tokens and granting access.

Changes:

• Filter out disabled resources during initialization using Resource::isEnabled
• OAuth2 plans linked to disabled resources now return 401 Unauthorized
• Added test coverage for enabled/disabled resource filtering

Before: Disabling OAuth2 resource → tokens still validated → 200 OK
After: Disabling OAuth2 resource → token validation blocked → 401 Unauthorized

Additional context

[gemini-code-assist]

Summary of Changes

Hello @vikrantgravitee, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical security oversight where disabling an OAuth2 resource did not prevent it from validating tokens, allowing unauthorized access. The changes ensure that the gateway properly respects the disabled state of OAuth2 resources by filtering them out during initialization. This prevents disabled resources from being loaded and used for token validation, thereby enforcing security policies and returning appropriate 401 Unauthorized responses for affected plans.

Highlights

• OAuth2 Resource Disablement: Disabled OAuth2 resources now correctly block token validation, preventing unauthorized access where previously tokens were still validated.
• Initialization Filtering: Resources are now filtered during initialization using Resource::isEnabled, ensuring that only active resources are loaded into the gateway.
• API Response Change: OAuth2 plans linked to disabled resources will now correctly return a 401 Unauthorized status, enforcing security policies.
• Test Coverage: New and updated test cases confirm that resource enablement/disablement is properly handled during the loading and initialization process.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to fix an issue where disabled OAuth2 resources were still being used. The change correctly filters out disabled resources during initialization. However, the filter is applied to all resource types, which could be a breaking change for non-OAuth2 resources that previously relied on being loaded even when disabled. I've left a comment suggesting to scope the filter to only OAuth2 resources to avoid unintended side effects. Additionally, I've pointed out a misleading test name in the new test case for better maintainability.