Hello Cloud list admins,
Can you please consider increasing the size of digest_size_threshold for this list (cloud)? I've received 7 digest emails today so far containing 2-3 emails each, and I'd prefer to receive 1 digest email per day with 20+ emails inside of it. Less emails = better for folks that want daily digests. This will not affect folks that are configured to receive individual emails.
Thanks for your consideration, Novem LInguae
-----Original Message----- From: cloud-request@lists.wikimedia.org cloud-request@lists.wikimedia.org Sent: Sunday, August 18, 2024 1:09 PM To: cloud@lists.wikimedia.org Subject: Cloud Digest, Vol 152, Issue 18
Send Cloud mailing list submissions to cloud@lists.wikimedia.org
To subscribe or unsubscribe, please visit https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
You can reach the person managing the list at cloud-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Cloud digest..."
Today's Topics:
1. Re: javascript tooling? (Travis Briggs)
----------------------------------------------------------------------
Message: 1 Date: Sun, 18 Aug 2024 13:08:44 -0700 From: Travis Briggs audiodude@gmail.com Subject: [Cloud] Re: javascript tooling? To: Wikimedia Cloud Services general discussion and support cloud@lists.wikimedia.org Message-ID: CAMPYpA5vo__8OvLosq6NCdjW4jWkRoSejrYAVPZJvZGk+ML-bw@mail.gmail.com Content-Type: multipart/alternative; boundary="0000000000000d6ba4061ffac3a6"
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/CORSNot SupportingCredentials .
- 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 rinfo&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=use rinfo&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 rinfo&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&ui prop=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.or g/ _______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.or g/ _______________________________________________ Cloud mailing list -- cloud@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.or g/
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/
On Sun, Aug 18, 2024 at 2:20 PM novemlinguae@gmail.com wrote:
Hello Cloud list admins,
Can you please consider increasing the size of digest_size_threshold for this list (cloud)? I've received 7 digest emails today so far containing 2-3 emails each, and I'd prefer to receive 1 digest email per day with 20+ emails inside of it. Less emails = better for folks that want daily digests. This will not affect folks that are configured to receive individual emails.
Thanks for your consideration, Novem LInguae
The default digest size threshold in our Mailman3 deployment is apparently 30Kb. I just increased the setting to 1024Kb for the cloud@ list to better accommodate list messages with extensive quoting of the thread so far. Hopefully this will make things a bit nicer for those of you who are following via daily/weekly/monthly digest subscriptions.
Bryan