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 <r...@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 <r...@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 <siddhart...@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 <r...@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 <r...@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 <audiod...@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.virta...@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 <r...@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/
