Skip to content

fix: route plugin API requests through native HTTP#1928

Closed
Ebola-Chan-bot wants to merge 2 commits intoAcode-Foundation:mainfrom
Ebola-Chan-bot:fix/plugin-api-native-http-cors
Closed

fix: route plugin API requests through native HTTP#1928
Ebola-Chan-bot wants to merge 2 commits intoAcode-Foundation:mainfrom
Ebola-Chan-bot:fix/plugin-api-native-http-cors

Conversation

@Ebola-Chan-bot
Copy link
Contributor

Work around the plugin API CORS mismatch seen in the Android WebView. The upstream API currently responds with Access-Control-Allow-Origin: https://localhost while the app runs from http://localhost, which causes fetch-based plugin requests to fail even though the API is reachable.

Add helpers.requestJson() so remote JSON requests prefer cordova-plugin-advanced-http instead of a fetch fallback. For the plugin API workload the bridge overhead is negligible compared with network latency, while the native path avoids the WebView CORS policy mismatch entirely.

Update checkAPIStatus() to use the shared helper, await the async API status check in the sidebar extension panel, encode plugin search queries, and route plugin list, search, explore, and filtered requests in both plugin entry points through the shared JSON helper.

Work around the plugin API CORS mismatch seen in the Android WebView. The upstream API currently responds with Access-Control-Allow-Origin: https://localhost while the app runs from http://localhost, which causes fetch-based plugin requests to fail even though the API is reachable.

Add helpers.requestJson() so remote JSON requests prefer cordova-plugin-advanced-http instead of a fetch fallback. For the plugin API workload the bridge overhead is negligible compared with network latency, while the native path avoids the WebView CORS policy mismatch entirely.

Update checkAPIStatus() to use the shared helper, await the async API status check in the sidebar extension panel, encode plugin search queries, and route plugin list, search, explore, and filtered requests in both plugin entry points through the shared JSON helper.
@Ebola-Chan-bot Ebola-Chan-bot marked this pull request as ready for review March 8, 2026 05:57
Copilot AI review requested due to automatic review settings March 8, 2026 05:57
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Mar 8, 2026

Greptile Summary

Summary

This PR fixes a real CORS mismatch between the Acode WebView origin (http://localhost) and the plugin API's Access-Control-Allow-Origin: https://localhost header by routing all plugin API requests through cordova-plugin-advanced-http (native HTTP) instead of the browser's fetch.

Key Changes

  • helpers.requestJson(url, headers?) — new helper that delegates to nativeHttp.get; throws if the Cordova plugin is absent (intentional, no fetch fallback).
  • checkAPIStatus() updated — now uses requestJson internally and wraps JSON parse errors with URL context for easier debugging.
  • await helpers.checkAPIStatus() bug fix — adds missing await in loadExplore and searchPlugin in extensions/index.js, fixing a previously un-awaited Promise that made the API-down guard always pass.
  • encodeURIComponent on search queries — properly encodes name query parameters to prevent malformed URLs when queries contain special characters.
  • package-lock.json — peer dependency housekeeping only; no version changes.

Technical Approach

The CORS workaround is correct: the native HTTP path bypasses WebView CORS policies entirely and avoids the mismatch. All plugin list, search, explore, and filter calls in both plugins.js and extensions/index.js are routed through the new shared helper. The JSON parsing already includes error wrapping with endpoint context, making failures easier to debug.

The intentional hard-throw when native HTTP is unavailable (no fetch fallback) aligns with the design goal: this feature exists specifically to work around Android WebView CORS issues, not to provide a cross-platform plugin API transport. All call sites have appropriate error handling that degrades gracefully to user-facing error messages.

Confidence Score: 4/5

  • Safe to merge for Android production; the CORS workaround is correct and the await fix is a genuine correctness improvement.
  • The CORS fix is sound and addresses a real issue in the Android WebView. The await bug fix in checkAPIStatus is a genuine correctness improvement. All call sites have proper error handling. The intentional hard-throw when native HTTP is unavailable is a deliberate design choice aligned with the PR's goal (Android-native HTTP transport, not cross-platform fallback). No functional bugs identified.
  • No files require special attention.

Last reviewed commit: f6e5d52

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR routes plugin registry/API traffic through Cordova’s native HTTP layer to avoid Android WebView CORS issues caused by an upstream Access-Control-Allow-Origin mismatch.

Changes:

  • Added a shared helpers.requestJson() helper that performs JSON GETs via cordova-plugin-advanced-http, and updated helpers.checkAPIStatus() to use it.
  • Updated the Extensions sidebar panel to await the API status check, encode search queries, and route list/search/explore/filter requests through helpers.requestJson().
  • Updated the Plugins page to encode remote search queries and route list/filter/search requests through helpers.requestJson().

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File Description
src/utils/helpers.js Adds a native-HTTP JSON helper and reworks API status checks to use it.
src/sidebarApps/extensions/index.js Switches plugin registry fetches to the shared native JSON helper; fixes missing await and URL-encodes search queries.
src/pages/plugins/plugins.js Switches plugin registry fetches to the shared native JSON helper and URL-encodes search queries.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Attach endpoint context to native HTTP JSON parsing failures so malformed 200 responses from the plugin API no longer surface as context-free SyntaxError exceptions.

Restore actionable logging for remote plugin search failures by including both the query text and resolved search URL in the error path.

Keep the plugin API transport strictly on the native HTTP path and document why fetch fallback is intentionally rejected in this codepath, since the WebView CORS mismatch is the bug this branch exists to avoid.

Record the current npm lockfile state produced by the branch after dependency installation so the submodule remains internally consistent.
@bajrangCoder
Copy link
Member

LGTM!

but you are wrong regarding app runs on http://localhost, as it runs on https://localhost. that's why server only allow this origin

@UnschooledGamer
Copy link
Member

@greptileai review again

@UnschooledGamer
Copy link
Member

@Ebola-Chan-bot Raunak (bajrangCoder) is correct about pointing out that the app runs on HTTPS. This can be found while inspecting the app with the Eruda console.

Overall the code seems fine to me

@Ebola-Chan-bot
Copy link
Contributor Author

Ebola-Chan-bot commented Mar 10, 2026

It has been confirmed that this bug was accidentally introduced by my debugging system. There is nothing that really needs to be fixed. Thank you and apologize for the interruption.

@Ebola-Chan-bot Ebola-Chan-bot deleted the fix/plugin-api-native-http-cors branch March 10, 2026 04:16
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.

4 participants