Title: [Bug] PCGamingWiki metadata import broken after API changes (403 / cargoquery permissiondenied)
Description
PCGamingWiki metadata import is currently broken in Drop.
When importing a game, Drop performs requests against the PCGamingWiki Cargo API and receives HTTP 403 responses.
Example from the Drop container logs:
AxiosError: Request failed with status code 403
URL:
https://www.pcgamingwiki.com/w/api.php?action=cargoquery&tables=Infobox_game&fields=Infobox_game._pageID%3DPageID%2CInfobox_game._pageName%3DPageName%2CInfobox_game.Cover_URL%2CInfobox_game.Released&where=Infobox_game._pageName%3D%22Exapunks%22&format=json
Headers:
User-Agent: axios/1.12.0
Additional testing
The same container can access the normal MediaWiki API successfully when using a descriptive User-Agent.
Example:
fetch(
"https://www.pcgamingwiki.com/w/api.php?action=query&format=json&meta=siteinfo",
{
headers: {
"User-Agent": "Drop/1.0 (self-hosted)"
}
}
)
Result:
HTTP 200
However, when testing the same cargoquery endpoint manually with a descriptive User-Agent, the HTTP request itself succeeds, but PCGamingWiki returns:
{
"error": {
"code": "permissiondenied",
"info": "You don't have permission to run arbitrary Cargo queries."
}
}
So there seem to be two separate compatibility issues:
- Drop currently sends the generic User-Agent "axios/1.12.0", which can cause HTTP 403 responses.
- Anonymous Cargo queries are no longer permitted by PCGamingWiki, so the current PCGamingWiki provider cannot complete its existing cargoquery requests even with a proper User-Agent.
Current Drop request
Drop currently queries:
action=cargoquery
tables=Infobox_game
Expected behavior
PCGamingWiki metadata import should either:
- use the currently supported PCGamingWiki API/authentication method,
- use a non-Cargo endpoint if available,
- or fail gracefully / allow the PCGamingWiki metadata provider to be disabled.
Actual behavior
Game metadata import logs repeated PCGamingWiki errors and the provider is effectively unusable.
Environment
- Docker
- Image: ghcr.io/drop-oss/drop:latest
- PostgreSQL 14
- Reverse proxy in front of Drop, but the issue is reproducible directly from inside the Drop container and is unrelated to the proxy
- PCGamingWiki connectivity, DNS and TLS are working correctly from inside the container
Notes
A configuration option to disable the PCGamingWiki provider would also be useful as a temporary workaround while API compatibility is being restored.
Title: [Bug] PCGamingWiki metadata import broken after API changes (403 / cargoquery permissiondenied)
Description
PCGamingWiki metadata import is currently broken in Drop.
When importing a game, Drop performs requests against the PCGamingWiki Cargo API and receives HTTP 403 responses.
Example from the Drop container logs:
AxiosError: Request failed with status code 403
URL:
https://www.pcgamingwiki.com/w/api.php?action=cargoquery&tables=Infobox_game&fields=Infobox_game._pageID%3DPageID%2CInfobox_game._pageName%3DPageName%2CInfobox_game.Cover_URL%2CInfobox_game.Released&where=Infobox_game._pageName%3D%22Exapunks%22&format=json
Headers:
User-Agent: axios/1.12.0
Additional testing
The same container can access the normal MediaWiki API successfully when using a descriptive User-Agent.
Example:
fetch(
"https://www.pcgamingwiki.com/w/api.php?action=query&format=json&meta=siteinfo",
{
headers: {
"User-Agent": "Drop/1.0 (self-hosted)"
}
}
)
Result:
HTTP 200
However, when testing the same cargoquery endpoint manually with a descriptive User-Agent, the HTTP request itself succeeds, but PCGamingWiki returns:
{
"error": {
"code": "permissiondenied",
"info": "You don't have permission to run arbitrary Cargo queries."
}
}
So there seem to be two separate compatibility issues:
Current Drop request
Drop currently queries:
action=cargoquery
tables=Infobox_game
Expected behavior
PCGamingWiki metadata import should either:
Actual behavior
Game metadata import logs repeated PCGamingWiki errors and the provider is effectively unusable.
Environment
Notes
A configuration option to disable the PCGamingWiki provider would also be useful as a temporary workaround while API compatibility is being restored.