TLDR: - Report issues to https://phabricator.wikimedia.org/T289318 - If you use an autofill password manager, change the beta.*wmflabs*.org URL to beta.*wmcloud*.org. - If you maintain any automated requests to Beta Cluster, update your URLs. - In the future, browsers will enforce cookie restrictions for *.beta.wmcloud.org the same way as *.org.

Hi all,

Back in 2020, the wmcloud.org domain became the default for projects hosted in Cloud VPS https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS, the cloud computing infrastructure provided by Wikimedia Cloud Services. [1][2] This follows the rebranding of Wikimedia Labs in 2017. [3][4] While most of the 200+ Cloud VPS projects can (or have) migrated their subdomains relatively easily, the Beta Cluster project is a bit more complicated.

There are assumptions at every level that the Beta equivalent of a production site like en.wikipedia.org lives at en.wikipedia.beta.*wmflabs*.org (including Varnish, TLS cert, Apache, Puppet, MediaWiki multiversion routing, MediaWiki wmf-config, Swift, Puppet, and WikimediaDebug).

Last month, I audited the services at each of these levels (their Hiera data, Puppet manifests, and Apache config) and any relevant MediaWiki configuration (e.g. Interwiki maps, LocalVHost proxy, CORS grants, Content-Security-Policy grants, UrlShortener, GlobalUserPage, and FileImporter) and identified what needs to change, whether it can support both, and what other thing it requires to add/change first to come up with an order of execution, to ensure a smooth transition.

As of last month, Wednesday June 4th, all wikis in the Beta Cluster support a beta.wmcloud.org hostname as alias, in addition to the canonical beta.wmflabs.org subdomain.

Over the past week, I've switched the canonical hostname for Beta Wikidata, Beta Commons, Beta Wikipedia, and other Beta Cluster wikis and services from beta.wmflabs.org to beta.wmcloud.org. This means pageview URLs such as https://en.wikipedia.beta.wmflabs.org/wiki/Special:Blankpage now redirect to https://en.wikipedia.beta.wmcloud.org/wiki/Special:Blankpage. Requests to /w/api.php, /w/rest.php, and most other services work both ways and don't (yet) redirect.

As part of this transition, I eliminated a few Beta-specific inconsistencies. Read the task for details, but the more notable ones include: * Wikidata hostname: wikidata.beta -> www.wikidata.beta. This now includes "www." to match prod. This makes beta/prod config syncing less error prone in the future, and fixes the last exemption to the expectation that all wikis have a two-segment domain name. It also simplifies TLS certs routing. * Multiversion routing, now translates automatically and re-uses production logic instead of needing its own. * Cookie and CORS restrictions. https://github.com/publicsuffix/list/pull/2527 [5]

ipedia.org and zh.wikipedia.org are

: I've requested that PSL include beta.wmcloud.org so that the different domains are treated as their own origins in the browser. This will make testing of CentralAuth CORS

If you have an autofill in your password manager associated with a domain like beta.wmflabs.org or auth.wikimedia.beta.wmflabs.org, change this to beta.wmcloud.org accordingly. Also, if you still have entries based on pre-SUL3 logins for en.wikipedia.beta.wmflabs.org or login.wikimedia.beta.wmflabs.org, you may want to remove or update those as well while at it.

If you maintain any automated requests to Beta Cluster (such as demos, test fixtures, etc), please update your URLs accordingly. In a couple of weeks, I'll change make these domains redirect which may break or change behaviour of scripts that don't expect HTTP redirects. See also: Codesearch https://codesearch.wmcloud.org/search/?q=%5C.beta.wmflabs.org. While at it, if the code in question should not actually make a request to the Beta Cluster, consider using a TLD such as "foobar.example" instead.

If you encounter any issues, please report them to https://phabricator.wikimedia.org/T289318.

-- Timo Tijhof, MediaWiki Engineering, Wikimedia Foundation.

[1]: https://wikitech.wikimedia.org/wiki/News/Wmcloud.org [2]: https://wikitech.wikimedia.org/wiki/News/2020_Phasing_out_the_.wmflabs_domai... [3]: https://phabricator.wikimedia.org/T166404 (FY17-18 P10.2: Rebranding Labs) [4]: https://wikitech.wikimedia.org/wiki/Help:Labs_labs_labs

[5] Addendum:

Browsers allow cookies to be shared by subdomains of the same parent, unless that parent is an eTLD https://en.wikipedia.org/wiki/Public_Suffix_List like ".org" or ".co.uk" because two domains may have a different owner. The list of eTLDs is known as the "public suffix list", and mostly contains what you'd expect: suffixes that you can buy a domain name under from a domain registrar. However, there is no technical reason why money needs to be involved. For example, github.io and our own toolforge.org are also considered public suffixes. While you can't manage domain names under these in the traditional way, they nonetheless allow different people to independently host web pages under their own domain, which would otherwise be at risk of tracking cookies and cross-site scripting.

Beta Cluster wikis were essentially all equal subdomains under the same domain name (beta.wmflabs.org). This meant that, unlike in production, a domain like en.wikipedia.beta.wmflabs.org could read cookies from auth.wikimedia.beta.wmflabs.org. Last year, in order to realistically test authentication in the Beta Cluster for the MediaWiki SUL3 project https://www.mediawiki.org/wiki/MediaWiki_Platform_Team/SUL3, we moved one wiki (test2.wikipedia.beta) from beta.wmflabs.org to beta.wmcloud.org, so that it would not be a sibling (T355281 https://phabricator.wikimedia.org/T355281). Todays migration essentially reverses this, because all wikis are now under the same umbrella again. This doesn't break anything, because this actually grants the sites more power, not less; and given that production uses separate domains, we don't have code relying on this anyway. But, it was of course valuable to be able to validate this with strict enforcement by the browser.

To solve this going forward, I asked Mozilla to include "beta.wmcloud.org" in the Public Suffix List. This is routinely pulled into downstream repos by other browser vendors, and tools like Curl. This means wikipedia.beta and wiktionary.beta will be considered separate domains, just like they are in production.

If you're curious how this works, check https://github.com/publicsuffix/list/pull/2527.