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-requ...@lists.wikimedia.org <cloud-requ...@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-ow...@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 <audiod...@gmail.com>
Subject: [Cloud] Re: javascript tooling?
To: Wikimedia Cloud Services general discussion and support
<cloud@lists.wikimedia.org>
Message-ID:
<campypa5vo__8ovlosq6ncdjw4jwkrosejryavpzjvzgk+ml...@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 <sarkarao...@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 <audiod...@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 <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=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.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.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/
>
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 16923 bytes
Desc: not available
------------------------------
Subject: Digest Footer
_______________________________________________
Cloud mailing list -- cloud@lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
------------------------------
End of Cloud Digest, Vol 152, Issue 18
**************************************
_______________________________________________
Cloud mailing list -- cloud@lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
