Skip to content

Use configured OAuth2 provider class from config#10900

Merged
TorstenDittmann merged 1 commit into1.8.xfrom
fix-use-oauth-classnames-from-config
Dec 4, 2025
Merged

Use configured OAuth2 provider class from config#10900
TorstenDittmann merged 1 commit into1.8.xfrom
fix-use-oauth-classnames-from-config

Conversation

@TorstenDittmann
Copy link
Copy Markdown
Contributor

What does this PR do?

Use configured OAuth2 provider class from config like it is done here:

https://github.com/appwrite/appwrite/blob/1.8.x/app/controllers/api/account.php#L1317-L1321

Checklist

  • Have you read the Contributing Guidelines on issues?
  • If the PR includes a change to an API's metadata (desc, label, params, etc.), does it also include updated API specs and example docs?

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Dec 4, 2025

📝 Walkthrough

Walkthrough

The pull request refactors OAuth2 provider class resolution from hard-coded namespace patterns to configuration-based lookup. In app/controllers/api/account.php, three occurrences of direct provider class construction are replaced with retrieval from a centralized oAuthProviders configuration. A similar change is applied to app/controllers/api/avatars.php. Each location now validates that the resolved class exists, throwing PROJECT_PROVIDER_UNSUPPORTED if missing, before proceeding with OAuth2 logic.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Repetitive pattern: The same refactoring logic is applied consistently across multiple locations (3 in account.php, 1+ in avatars.php), reducing cognitive load per instance
  • Straightforward configuration lookup: Replacing dynamic class name construction with configuration-based retrieval is a clear, linear change
  • Limited file spread: Changes are contained to two related files in the OAuth2 handling layer

Areas requiring attention:

  • Verify the oAuthProviders configuration key access is consistent across all occurrences
  • Confirm the class existence validation check (guard clause for PROJECT_PROVIDER_UNSUPPORTED) is implemented correctly in each location
  • Ensure error handling maintains parity with previous behavior where applicable
  • Check that all previous hard-coded resolution patterns have been replaced (no mixed approaches)

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: using configured OAuth2 provider classes from config instead of hard-coded resolution.
Description check ✅ Passed The description is related to the changeset, explaining the PR applies a pattern from account.php to other files and references the contributing guidelines.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix-use-oauth-classnames-from-config

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.

@github-actions
Copy link
Copy Markdown

github-actions bot commented Dec 4, 2025

Security Scan Results for PR

Docker Image Scan Results

Package Version Vulnerability Severity
imagemagick 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-c++ 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-dev 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-heic 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-jpeg 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-jxl 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-libs 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-openexr 7.1.2.3-r0 CVE-2025-62171 HIGH
imagemagick-webp 7.1.2.3-r0 CVE-2025-62171 HIGH
libecpg 17.6-r0 CVE-2025-12818 HIGH
libecpg-dev 17.6-r0 CVE-2025-12818 HIGH
libpng 1.6.47-r0 CVE-2025-64720 HIGH
libpng 1.6.47-r0 CVE-2025-65018 HIGH
libpng-dev 1.6.47-r0 CVE-2025-64720 HIGH
libpng-dev 1.6.47-r0 CVE-2025-65018 HIGH
libpq 17.6-r0 CVE-2025-12818 HIGH
libpq-dev 17.6-r0 CVE-2025-12818 HIGH
libxml2 2.13.8-r0 CVE-2025-49794 CRITICAL
libxml2 2.13.8-r0 CVE-2025-49796 CRITICAL
libxml2 2.13.8-r0 CVE-2025-49795 HIGH
libxml2 2.13.8-r0 CVE-2025-6021 HIGH
postgresql17-dev 17.6-r0 CVE-2025-12818 HIGH
github.com/containerd/containerd/v2 v2.0.2 CVE-2024-25621 HIGH
golang.org/x/crypto v0.31.0 CVE-2025-22869 HIGH
golang.org/x/oauth2 v0.24.0 CVE-2025-22868 HIGH
stdlib 1.22.10 CVE-2025-47907 HIGH
stdlib 1.22.10 CVE-2025-58183 HIGH
stdlib 1.22.10 CVE-2025-58186 HIGH
stdlib 1.22.10 CVE-2025-58187 HIGH

Source Code Scan Results

🎉 No vulnerabilities found!

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
app/controllers/api/account.php (1)

889-907: Avoid treating non‑OAuth sessions as unsupported providers in updateSession

Here $provider comes from the session and can be values like email, anonymous, phone, etc., which are not present in Config::getParam('oAuthProviders'). The new code will:

  • Index $oAuthProviders[$provider]['class'] for these non‑OAuth providers (risking notices/warnings), and
  • Throw PROJECT_PROVIDER_UNSUPPORTED, breaking PATCH /v1/account/sessions/:sessionId for non‑OAuth sessions.

You only want to resolve/config‑check a class for providers that are actually registered in oAuthProviders. A minimal fix:

-        $provider = $session->getAttribute('provider', '');
-        $refreshToken = $session->getAttribute('providerRefreshToken', '');
-        $oAuthProviders = Config::getParam('oAuthProviders');
-        $className = $oAuthProviders[$provider]['class'];
-        if (!\class_exists($className)) {
-            throw new Exception(Exception::PROJECT_PROVIDER_UNSUPPORTED);
-        }
-
-        if (!empty($provider) && \class_exists($className)) {
+        $provider = $session->getAttribute('provider', '');
+        $refreshToken = $session->getAttribute('providerRefreshToken', '');
+        $oAuthProviders = Config::getParam('oAuthProviders');
+        $className = null;
+
+        // Only treat providers registered in config as OAuth2 providers
+        if (!empty($provider) && isset($oAuthProviders[$provider])) {
+            $className = $oAuthProviders[$provider]['class'] ?? null;
+
+            if (empty($className) || !\class_exists($className)) {
+                throw new Exception(Exception::PROJECT_PROVIDER_UNSUPPORTED);
+            }
+        }
+
+        if (!empty($provider) && !empty($className)) {
             $appId = $project->getAttribute('oAuthProviders', [])[$provider . 'Appid'] ?? '';
             $appSecret = $project->getAttribute('oAuthProviders', [])[$provider . 'Secret'] ?? '{}';
 
             $oauth2 = new $className($appId, $appSecret, '', [], []);
             $oauth2->refreshTokens($refreshToken);

This keeps the new config‑driven behavior for OAuth2 providers, while leaving email/phone/anonymous sessions unaffected.

🧹 Nitpick comments (1)
app/controllers/api/avatars.php (1)

91-107: Guard against missing/misconfigured OAuth provider config entry

Indexing $oAuthProviders[$provider]['class'] assumes both the provider key and class field exist; if they don’t, PHP will emit notices before you throw PROJECT_PROVIDER_UNSUPPORTED. You can avoid that and keep the same behavior by coalescing and checking for an empty class name:

-        $oAuthProviders = Config::getParam('oAuthProviders');
-        $className = $oAuthProviders[$provider]['class'];
-        if (!\class_exists($className)) {
-            throw new Exception(Exception::PROJECT_PROVIDER_UNSUPPORTED);
-        }
+        $oAuthProviders = Config::getParam('oAuthProviders');
+        $className = $oAuthProviders[$provider]['class'] ?? null;
+        if (empty($className) || !\class_exists($className)) {
+            throw new Exception(Exception::PROJECT_PROVIDER_UNSUPPORTED);
+        }
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 379b85b and fad29ee.

📒 Files selected for processing (2)
  • app/controllers/api/account.php (3 hunks)
  • app/controllers/api/avatars.php (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
app/controllers/api/account.php (1)
src/Appwrite/Extend/Exception.php (1)
  • Exception (7-465)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: scan
  • GitHub Check: Setup & Build Appwrite Image
  • GitHub Check: Setup & Build Appwrite Image
🔇 Additional comments (1)
app/controllers/api/account.php (1)

1455-1482: Config‑driven OAuth2 class resolution in OAuth flows looks correct

Both the OAuth2 redirect handler and the OAuth2 token creation endpoint now:

  • Resolve the provider class via Config::getParam('oAuthProviders')[$provider]['class'], and
  • Throw PROJECT_PROVIDER_UNSUPPORTED when the configured class is missing.

Because provider is already constrained by new WhiteList(array_keys(Config::getParam('oAuthProviders')), true) on both routes, the lookup is safe, and this aligns behavior across all OAuth entry points. No further changes needed here.

Also applies to: 1955-2015

@github-actions
Copy link
Copy Markdown

github-actions bot commented Dec 4, 2025

✨ Benchmark results

  • Requests per second: 1,220
  • Requests with 200 status code: 219,710
  • P99 latency: 0.158681968

⚡ Benchmark Comparison

Metric This PR Latest version
RPS 1,220 1,249
200 219,710 224,829
P99 0.158681968 0.166507933

@TorstenDittmann TorstenDittmann merged commit a0cf731 into 1.8.x Dec 4, 2025
43 checks passed
@TorstenDittmann TorstenDittmann deleted the fix-use-oauth-classnames-from-config branch December 4, 2025 16:58
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