Reading https://meta.wikimedia.org/w/api.php?action=help&modules=shortenurl - doesn't seem to require a CSRF token, so I'm not sure that CORS is needed here? (more specifically, you can use the generic origin=* I think).

Although query.wikidata.org is fairly trusted, its still nice to reduce exposure by limiting CORS in places that don't strictly need it.

origin=* makes the request anonymous. Apparently anonymous users are allowed to shorten URLs (subject to a rate limit), but I think it would be nicer to tie the URLs to the user if they’re logged in.

(I’m also surprised at the lack of a CSRF token, but if that’s an issue, it’s outside the scope of this task.)

Moving from email here:

Does the Query Service needs to, in any way, act on the UrlShortener API as the user who is currently logged-in? Trusted or not, that

Well, that was kinda my question from the start. Right now, WDQS UI does not know anything about any users, so if we could keep it this way, it'd be fine with me.
That said, I can see a value in ability of the user to log in and then track the short URLs for the query they are creating. So if it is not too much trouble, may be a nice addition. That said, it is in no way required for the URL shortening in the UI to work, on the contrary - it is currently not a supported mode and will require additional code to support.

is logged-in on the main domain. Given that serving app-tokens to the client-side javascript of the query service would be a problem, this means you'll probably want to make that API request server-side instead. Thus leaving two options:

WDQS UI does not have server side, so that definitely would be a problem.

• Use the API with auth, as an OAuth user with its credentials and the request made server-side, possibly exposed indirecrtly via wikidata-query's own API.

WDQS UI does not have server side, as I mentioned. While we did plan to add OAuth capabilities for Blazegraph as a module for other reasons (see T179879) it is a very long-term plan and is not something planned for right now.

When WDQS first launched, we intentionally removed it from the CORS whitelist (previously *.wikidata.org was whitelisted IIRC) as a security hardening measure.

I would suggest that WDQS plan to shorten URLs anonymously. Since it's happening client-side (AIUI), it shouldn't run into rate limits unless someone is shortening too many URLs. We should revisit this if it's actually a problem of course, but I don't think we should be weakening our hardening measures for a problem that we don't even know exists.