I'm discovering and exploring this issue with Gemini, saying the following :

The Essential Header

The primary change needed is the addition of the Access-Control-Allow-Origin header.

For specific access (Recommended):
Access-Control-Allow-Origin: https://your-tool-name.toolforge.org
This tells the browser to only allow requests from your specific Toolforge URL.

For public access (Less secure):
Access-Control-Allow-Origin: *
This allows any domain to make a request, which is often used for public APIs but can be risky if sensitive data is involved.

Also, Gemini returns me the following :

A Quick Reality Check
Since phabricator.wikimedia.org is a production service managed by Wikimedia Foundation SREs, they generally do not allow cross-origin requests directly from the browser for security reasons (to prevent CSRF and data leaking).
The standard workaround:
Instead of making the request from the user's browser (client-side), make the request from your Toolforge backend (server-side).

1. Your browser sends a request to your Toolforge Tool.
2. Your Tool (Node.js, Python/Flask, PHP) fetches the data from the Phabricator API.
3. Your Tool sends the data back to your browser

Since CORS only exists in the browser, a server-to-server request won't trigger this error.

How do you plan to use the Phabricator API from the browser as all requests require authentication?

Hello @taavi ,

Personal usecase

I haven't decided that yet, your advice are welcome. Given I don't see in https://phabricator.wikimedia.org/conduit/ #Token section any option for a logged in Phabricator user to query a token... (Wikimedia's).
Given my personal token is, I believe, a read-only Conduit API token on a public Phabricator API. Therefore the risk is that someone grabs my token and burns through API rate limits, then get blocked. Not severe.

Also, I'm considering the following :

1. hard coded / low visibility (code side) : this dashboard is a secret dashboard for managers, there will be no public link to it on lingualibre.org , with average of ~4 ping per month (mostly, when writing reports). I just hard code and share my personal Token. (I suspect you wont advise that)
2. url parameter & localStorage (client side): add a parameter ?phabricator=PHABRICATOR-TOKEN, so each manager submit their own token, which they get from https://phabricator.wikimedia.org/settings/user/USERNAME/page/apitokens/
3. Nginx proxy_pass (server side): I may edit my ngnix file's proxy_pass block (already in use for CORS walk-around), to insert the token server side. My token is therefore only exchanged between lingualibre.wmcloud.org server proxy and phabricator.wikimedia.org/api/. Visitors' devices never see the token.

------------------------------> [EDIT]: I implemented the 3rd option. <-----------------------------

In last resorts, there "may" be a way with recently coded mcp-phabricator by @egardner and @Michael . But it's currently beyond my current skills and lacks functions to queries Users ( [[ https://phabricator.wikimedia.org/api/user.search?api.token=TOKEN&constraints[phids][0]=PHID-USER-hqja3tl7qdiets4lmvep | ex, without token ]] ).

Others usecases

The length we have to go with CORS and private tokens obfuscation to fetch simple public-facing data is unusual for the wikimedia ecosystem. From a wikimedian POV I would still encourage --if WMF's HR allows it, while risks is known and minor-- to move to a more open API access (for READ), as is the case for other wikimedia APIs used in my project. From toolforge.org and wmcloud.org especially.

cc @Aklapper and @brennen

Hi, this lacks a use case: an underlying actual problem to solve.

Please also explain what exactly you want to query in Wikimedia Phabricator. And why. And how.

Given my personal token is, I believe, a read-only Conduit API token on a public Phabricator API.

Read-only Conduit API tokens do not exist.

if WMF's HR allows it

What is "WMF's HR"?

@Yug: Could you please answer the last comment? Thanks in advance!