Tool:Gitlab-content

Toolforge tools
Wikimedia GitLab content proxy
Website	https://gitlab-content.toolforge.org/
Description	A proxy service that can be used to fetch content from gitlab.wikimedia.org with a caller defined mime-type.
Keywords	gitlab, proxy
Author(s)	BryanDavis
Maintainer(s)	BryanDavis (View all)
Source code	gitlab:toolforge-repos/gitlab-content
License	GNU General Public License 3.0 or later
Issues	Open tasks · Report a bug
Admin log	Tools.gitlab-content/SAL

Wikimedia GitLab content proxy (gitlab-content) is a reverse proxy for fetching raw file content from gitlab.wikimedia.org. This functionality can be combined with mw.loader.load to enable side loading content hosted on our gitlab server from a userscript, a user's common.js and global.js, or similar JavaScript workflow customization contexts.

Directly fetching a raw file from gitlab will always respond with a text/plain mime type to prevent various cross-site scripting (XSS) attacks against gitlab itself. By running in an isolated Toolforge domain gitlab-content can safely add useful mime types like text/javascript or text/css.

The general use envisioned for a proxy like this is enabling a collaborative development workflow including linting, unit tests, code generation, and code review on gitlab.wikimedia.org without a separate copy-and-paste step to publish scripts to a Wikimedia wiki for integration and acceptance testing. When development slows, publishing the scripts directly on a wiki will generally be quicker and more secure for long term use.

Usage

https://gitlab-content.toolforge.org/{REPO}/-/raw/{PATH}?mime={MIME}

{REPO}: gitlab.wikimedia.org repo name
{PATH}: path to file within the repo including branch name or commit hash
{MIME}: mime type to apply to the content (defaults to text/plain)

The URL format matches gitlab's internal URLs for raw content. This should help folks find the right URL by browsing in gitlab.wikimedia.org, changing the hostname to gitlab-content.toolforge.org, and adding the desired mime type specification.

mw.loader.load( 'https://gitlab.wikimedia.org/bd808/example-userscripts/-/raw/6f6adea1e14f2c6dbaef23d5f512beb62c22a7bf/hello-world.js?mime=text/javascript' );

FAQs

What is the point of this tool?

Userscripts are powerful tool for changing and creating workflows in MediaWiki wikis. Communities like the technical contributors on English Wikipedia make and share many scripts that can be used to enhance your experience interacting with Wikimedia wikis.

Collaborating on the development of userscripts using pure on-wiki workflows can be difficult to painful. MediaWiki offers a security protection for userscripts that prevents anyone other than the User namespace owner and Interface administrators from editing a user's personal CSS and JS pages. This is a good thing for keeping bad actors from sneaking in and messing with your scripts. It can be a barrier to collaboration however. Leaving code review comments, running automated linters and functional tests, and other collaborative development activities are common on gitlab.wikimedia.org. On-wiki you mostly have talk pages and the ability to cut-and-paste content to other systems where you can run development tools.

Is loading javascript via Toolforge and gitlab.wikimedia.org a good idea?

Maybe, but also maybe not. There are a number of risks to consider before using this proxy or any similar service that will mix content from off-wiki with your on-wiki browsing.

The first risk to consider is that your web browser will be interacting with the gitlab-content.toolforge.org tool. Toolforge includes built-in protections to hide your IP address from the operators of the tool, but they will be able to see your user-agent. They will also have the opportunity to put any content they want into the pages served by the tool. Reading the public source code at gitlab:toolforge-repos/gitlab-content and verifying things about the tool maintainers themselves and their status in the Wikimedia community are your controls against their possible bad behavior.

Another risk is that the gitlab repo you are pulling data from might also be maintained by bad actors or compromised. The best protection against compromise would be using a git commit hash in the URL you fetch from the wiki page. You can read up on how git commit hashes work and things Linus Torvalds has said about malicious collisions to convince yourself how secure this is.

Depending on why you are loading content this way, pinning to a particular commit hash might not be feasible. In that case you run a few more risks in trusting the folks who have commit rights to the git repository. They will have the ability to change file contents or even delete the files. They might commit a file that includes invalid content that causes problems with your browsing experience or other workflows when it is loaded.

If your risk model includes uptime or stability, the use of the gitlab-content proxy will increase those risks. This happens because you are adding additional services that might fail to your request path. The Toolforge front proxy might go down. The Toolforge Kubernetes cluster might go down. The Ingress service might go down. The tool's webservice might go down. The network between the tool and gitlab.wikimedia.org might go down. Gitlab.wikimedia.org might go down. DNS for some of these parts might go down. Any number of these things might happen at the same time.

Loading content via this proxy is without a doubt more risky than not doing so and only getting content from pages on a Wikimedia wiki. You need to decide for yourself if the risks are worth the rewards in your use case.

Is loading javascript from Toolforge against the standard Wikimedia privacy policy?

Not necessarily. You control your own common.js and can put anything you want into it. Similarly you can write a userscript as a subpage of your user page and put anything you want into it. Your choices expose you to risks, but they are risks you choose.

Gadgets, default gadgets, and site-wide common.js are a bit different. These are shared spaces and some of them affect people who do not even know they are there. These are not places where the maintainers of the proxy feel it should be used. They are not lawyers or at least certainly not your lawyer, so you will need to look elsewhere for specific advice about legal implications.

As the GNU General Public License Version 3 that the proxy is licensed under states: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Maintenance

The application runs from Toolforge under the "gitlab-content" tool account as a webservice using a buildservice managed container.

you@laptop:~$ ssh dev.toolforge.org
you@tools-bastion-12:~$ become gitlab-content
tools.gitlab-content@tools-bastion-12:~$ webservice status
Your webservice of type buildservice is running on backend kubernetes
tools.gitlab-content@tools-bastion-12:~$ toolforge build start https://gitlab.wikimedia.org/toolforge-repos/gitlab-content
Waiting for the logs... if the build just started this might take a minute
[prepare] 2025-05-08T22:29:04.717861346Z 2025/05/08 22:29:04 Entrypoint initialization
...
[step-results] 2025-05-08T22:29:36.306167467Z Built image tools-harbor.wmcloud.org/tool-gitlab-content/tool-gitlab-content:latest@sha256:0b1c622fa2ad995ae7630d2a945502713807dc4928165f342cb4ace2d23c004a
tools.gitlab-content@tools-bastion-12:~$ dologmsg 'Build new image from 2952bfc9'
tools.gitlab-content@tools-bastion-12:~$ webservice restart
Restarting.....
tools.gitlab-content@tools-bastion-12:~$ dologmsg 'Restarted to deploy new image from 2952bfc9'

Project history

The implementation of gitlab-content started at Wikimedia Hackathon 2025.^[1] The idea for the project came from work done to build a narrowly focused reverse proxy to enable collaboration on a userscript during "Sprinthackular II" in January 2025. Discussion of the generalized reverse proxy idea between bd808 and thcipriani surfaced a prior discussion about extending gitlab to support use case. GitLab has WONTFIX'ed several requests for similar functionality upstream.^[2]^[3]^[4] These rejections come generally from the XSS threat that serving arbitrary javascript content from the same domain as the GitLab software itself creates.^[5] Using the isolated gitlab-proxy.toolforge.org domain to host the reverse proxy provides browser sandboxing separation from the gitlab.wikimedia.org domain preventing that XSS issue from applying.