I tried adding an additional post earlier with that exact reasoning, but Cloudflare's WAF wasn't having any of it.
Here's what I had originally posted, after expansive editing to make it play nice with the WAF...
I can generate a guest-level API key on the ACP, and I can query stuff like this, with the right scope limitation set:
Code:
curl -H 'XF-Api-Key: rU5FfJgQzVVydI1JNuIO6UXYdCi3WDET' 'https://forum.some-domain-name.tld/api/'
which returns
Code:
{
"version_id": 2031070,
"site_title": "Some Forum Name",
"base_url": "https://forum.some-domain-name.tld",
"api_url": "https://forum.some-domain-name.tld/api/",
"key": {
"type": "guest",
"user_id": null,
"allow_all_scopes": false,
"scopes": {
"resource:read": true,
"resource_category:read": true,
"resource_rating:read": true
}
}
}
Then can add-in the scope:
/resources?limit=5' to the API URL endpont to get details.
I'd love it if the API functionality was greatly extended to:
1. Allow user-creatable API keys on the forum. With an expansive API control panel for the administration to dictate what can and cannot be allowed in user-generated API key scopes, in addition to setting API key overrides.
2. A setting to toggle global / anon access API to the forum API, but with greatly limited scope in what can be viewed (date posted, last updated, id, name of item, etc.)
The Admin-only API stuff is indeed a start, but is highly limiting for end-users like yourself.
Either way, I've added your addon to my forum, it shows promise!
XF does support
guest-type API keys (your
"type": "guest" output), so an app can read
resource:read /
resource_category:read without a user account at all. Your curl example is exactly the shape of request I'd want to make.
The constraint that actually bites is one step earlier: that key still has to be
generated in the ACP of the forum being queried (key creation is super-admin only - there's no end-user flow in core). You can do that on your own forum, or any you administer, which is why your example works against
forum.some-domain-name.tld. But you can't mint one on xenforo.com - so xenforo.com, the marketplace this add-on mostly checks, stays scrape-only for now.
For a self-hosted or third-party XFRM marketplace where you can mint a key like that, this add-on could query
/api/resources with it instead of scraping the page - cleaner and more reliable. That's the "check a marketplace via its API" opt-in on my roadmap, and your post is basically the reference implementation for it. If you'd be up for testing against your forum once I build it, that'd be ideal.
On your two asks - they're the right ones to put to XenForo, and the interesting part is how much of them is already reachable from an add-on rather than needing core changes:
- User-creatable keys - the
ApiKey entity and ManagerService can already mint scoped keys programmatically; what's missing is a front-end flow for a logged-in member to generate and revoke their own, with admin-controlled limits on which scopes they may request. That's an add-on UI problem, not a core-API gap.
- Scoped anonymous / global read - an API controller can already opt a specific endpoint out of the key requirement by overriding
allowUnauthenticatedRequest(); core's own oEmbed and OAuth2 controllers do exactly that, so a scoped public read is doable without touching core. There's just no global "make the whole API public" switch - it's per-endpoint by design, which is arguably the safer default anyway.
So a "public resource version API" is genuinely buildable as an add-on for any marketplace that installs it - it just can't retrofit xenforo.com itself. The pieces that are
not native, and would have to be built, are the operational ones: rate limiting, API usage logging, and an OpenAPI/Swagger spec.
If anything, the more interesting half is webhooks. XF already ships a native, signed, retrying webhook system, and add-ons can register their own event types - XFRM, for instance, fires one on a new resource version. So "new version released -> webhook" is mostly a configuration story today rather than something you'd build from scratch.
I'd still back a suggestion thread for the two core-level asks - user-generated tokens and a first-class public read mode would be cleaner coming from core than re-implemented per add-on.
There is a slight bug encountered with off-site hosted downloads, with the use developer site option unticked.
"Multi Prefix 2.17.3 - You have 2.17.2, latest is 2.17.3" Clicking download in this instance directs me to <
https://xenforo.com/community/resources/multi-prefix.6281/download> which is a "no permission to download page" as the downloaded is hosted off site by the addon author. Possible to link the download to the scraped link provided?
Confirmed and fixed in
v1.1.2 (just released).
It happened because he Download button always pointed at the marketplace's
/download path (
...resources/multi-prefix.6281/download). For an add-on whose author hosts the file off-site (XFRM external download URL), that is the "no permission to download" page you hit rather than a download.
I checked whether I could scrape the real download link from the resource page instead, but xenforo.com's page only exposes the version - its JSON-LD has no download URL, and there's no
/download link rendered for an external resource - so there's nothing reliable to point at. The fix: the Download button now shows only when there is a genuine direct link (when "prefer the developer's download site" is on and the add-on lists one). Otherwise the row's
View on XenForo.com link is the action - it opens the resource page, where the author's real download control is, hosted or off-site. So for Multi Prefix you'll land on the resource page instead of the dead-end.
