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=userinfo&formatversion=2&uiprop=rights

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=userinfo&formatversion=2&uiprop=rights
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.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
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.
- https://www.mediawiki.org/wiki/Vue.js

-- 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/