Okay that makes a lot of sense then. I bet for some endpoints you want to include OAuth credentials to act on behalf of a user.
-Travis
On Sun, Aug 18, 2024 at 1:01 PM Aoyan Sarkar sarkaraoyan@gmail.com wrote:
The browser does not allow you to pass in credentials (via cookies or Authenticafion header) when origin=*.
From MDN:
For requests without credentials, the literal value "*" can be specified
as a wildcard; the value tells browsers to allow requesting code from any origin to access the resource. Attempting to use the wildcard with credentials results in an error https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials .
- Aoyan Sarkar
On Sun, Aug 18, 2024 at 3:58 PM Travis Briggs audiodude@gmail.com wrote:
CORS is unrelated to authentication. It has nothing to do with what cookies you do or do not have. While a website could look at cookies when deciding whether to send the Access-Control-Allow-Origin header, that would be unusual.
origin=* should be all you ever need, because otherwise you're just telling the MW server to allow whatever you tell it. So it's just as good for the MW server to tell the browser that it allows everything. You don't gain any security by asking the MW server to only allow your specific origin for that request.
-Travis
On Sun, Aug 18, 2024 at 12:52 PM Roy Smith roy@panix.com wrote:
OK, I'm reading along at https://www.mediawiki.org/wiki/API:Cross-site_requests and this is starting to make sense. I see that origin=* forces anonymous mode. This is enough to get me started. At some point I'll certainly need to be authenticated, but I'll tackle that when I get to it.
On Aug 18, 2024, at 2:37 PM, Sportzpikachu via Cloud < cloud@lists.wikimedia.org> wrote:
Access-Control-Allow-Origin (and other related headers) is standard. `origin=*` is specific to the Action API, which requests MW to add the ACAO header.
`origin=localhost:5173` IIRC makes MW check the origin against a whitelist of sites that can use credentials, but origin=* is special in that MW allows CORS for anonymous requests (ie no cookies sent).
On 19 Aug 2024, at 02:32, Roy Smith roy@panix.com wrote:
OK, that worked, thanks. Surprisingly origin=localhost:5173 doesn't work, but I can live with that.
Is this a standard part of the CORS protocol, or something specific to the Action API?
On Aug 18, 2024, at 1:45 PM, Siddharth VP siddharthvp@gmail.com wrote:
Add origin=* in the API request query params. This tells the API to include Access-Control-Allow-Origin: * in the response headers. Don't put mode: no-cors.
On Sun, 18 Aug 2024 at 22:29, Roy Smith roy@panix.com wrote: So, after beating my head against this for a couple of days, I've come to the conclusion that I just don't understand how CORS works.
If I get the following URL: https://en.wikipedia.org/w/api.php?action=query&format=json&meta=use...
from a browser, I get what I expect:
{ "batchcomplete": true, "query": { "userinfo": { "id": 130326, "name": "RoySmith", "rights": [ etc }
On the command-line with curl, likewise something that makes sense:
{ "batchcomplete" : true, "query" : { "userinfo" : { "anon" : true, "id" : 0, etc }
But when I do the same fetch from inside a VUE app:
<template> <main> <button @click="getUserInfo">UserInfo!</button> </main> </template>
<script> export default { methods: { getUserInfo() { fetch(' https://en.wikipedia.org/w/api.php?action=query&format=json&meta=userinfo&formatversion=2&uiprop=rights', { mode: 'no-cors'}) .then(function (response) { response }) } } } </script>
I get a 200 response
Request URL: https://en.wikipedia.org/w/api.php?action=query&format=json&meta=use... Request Method: GET Status Code: 200 OK Remote Address: (elided) Referrer Policy: strict-origin-when-cross-origin
Request headers:
:authority: en.wikipedia.org :method: GET :path: /w/api.php?action=query&format=json&meta=userinfo&formatversion=2&uiprop=rights :scheme: https accept: */* accept-encoding: gzip, deflate, br, zstd accept-language: en-US,en;q=0.9 dnt: 1 priority: u=1, i referer: http://localhost:5173/ sec-ch-ua: "Not)A;Brand";v="99", "Google Chrome";v="127", "Chromium";v="127" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "macOS" sec-fetch-dest: empty sec-fetch-mode: no-cors sec-fetch-site: cross-site user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Response headers:
accept-ranges: bytes age: 2 cache-control: private, must-revalidate, max-age=0 content-disposition: inline; filename=api-result.json content-encoding: gzip content-length: 207 content-type: application/json; charset=utf-8 date: Sun, 18 Aug 2024 13:45:15 GMT nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0} report-to: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": " https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.netwo..." }] } server: mw-api-ext.eqiad.main-5744d5b77-fzvxz server-timing: cache;desc="pass", host;desc="cp1102" set-cookie: WMF-Last-Access=18-Aug-2024;Path=/;HttpOnly;secure;Expires=Thu, 19 Sep 2024 12:00:00 GMT set-cookie: WMF-Last-Access-Global=18-Aug-2024;Path=/;Domain=. wikipedia.org;HttpOnly;secure;Expires=Thu, 19 Sep 2024 12:00:00 GMT set-cookie: GeoIP=(elided) set-cookie: NetworkProbeLimit=0.001;Path=/;Secure;SameSite=Lax;Max-Age=3600 strict-transport-security: max-age=106384710; includeSubDomains; preload vary: Accept-Encoding x-cache: cp1102 miss, cp1102 pass x-cache-status: pass x-client-ip: (elided) x-content-type-options: nosniff x-frame-options: DENY
but the response body is empty. Chrome just says "Failed to load response data: No data found for resource with given identifier". I assume this is just Chrome's way of saying "Your brain is not big enough to understand how CORS works". Can anybody help me increase my brain capacity?
On Aug 15, 2024, at 2:36 PM, Roy Smith roy@panix.com wrote:
Thank you to everybody who offered advice. I've set up a Vue/Vite environment on my laptop and started working my way through the tutorials. Some stuff makes a lot of sense; other stuff not so much yet, but I'm working on cleaning out some old neural storage areas to make room for new knowledge.
I think what would help me at this point was being able to look at the source for some well-written Vue apps written to work in the wikipedia environment. If folks could point me to some examples, I would appreciate it. Are there higher-level wrappers around the Action API, like pywikibot for Python, or do you just do raw fetch calls on the API endpoints?
On Aug 8, 2024, at 1:14 PM, Travis Briggs audiodude@gmail.com wrote:
Vue.js is definitely a good option. I already had a lot of JavaScript experience, but I learned Vue at someone's recommendation for a wikimedia project and it was a great experience.
One quick tip that might help you: in the "old world" you might use jQuery or something to do AJAX requests (XHR). However, in modern browsers, the built-in `fetch` function is more than adequate for almost everything.
Also, I would highly recommend using create-vue to bootstrap your project, because it sets up all the complicated JavaScript "compilation" steps for you, and gives you commands so that you can just do "npm run build" and get a static site in a single directory.
Good luck! -Travis
On Thu, Aug 8, 2024 at 8:36 AM Kimmo Virtanen kimmo.virtanen@gmail.com wrote: Hi,
Vue.js is afaik current choice.
-- Kimmo
On Thu, Aug 8, 2024 at 6:34 PM Roy Smith roy@panix.com wrote: I'm about to embark on building a client-side javascript tool intended to help with enwiki's [[WP:DYK]] process. JS is not my strength (and what I do know about tooling is quite outdated) so I'm looking for advice on what's in common use in the WMF environment these days. If I'm going to learn some new tools, I figure I might as well learn what folks here are using. If only because it'll make it easier for me to mooch on other people for help :-)
As far as testing goes, I used to use JUnit. I gather that's pretty old-hat by now. What are you-all using?
And for app frameworks. Angular? React? I hear Vie might be the new hotness? I'm leaning more towards "easy to learn" vs "most powerful". _______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/ _______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/ _______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/ _______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/