| DamianZaremba | |
| Jul 15 2026, 4:13 PM |
| F93820689: Screenshot 2026-07-15 at 18.12.08.png | |
| Jul 15 2026, 4:13 PM |
Steps to replicate the issue (include links if applicable):
What happens?:
Tab is opened and refuses to load with ERR_BLOCKED_BY_RESPONSE
What should have happened instead?:
https://toolsadmin.wikimedia.org/tools/id/anomiebot should have loaded
Other information (browser name/version, screenshots, etc.):
I think this is actually an issue on the Striker (toolsadmin) side rather than the Toolhub side? Striker emits a cross-origin-opener-policy: same-origin header. That header prevents window.open("https://toolsadmin.wikimedia.org/...") from any page origin other than toolsadmin itself.
Per https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cross-Origin-Opener-Policy#noopener-allow-popups I think that switching to cross-origin-opener-policy: noopener-allow-popups would preserve the intended protection against cross-site leak attacks, but also let Toolhub or other sites use window.open() or target="_blank" as Toolhub actually uses.
The current header on the Striker side is the default SECURE_CROSS_ORIGIN_OPENER_POLICY setting for the django.middleware.security.SecurityMiddleware class.
@bd808 you're probably right.
I think this could be fixed with rel=noopener on the toolhub side also (I assume the protection is there to stop "remote" access to toolsadmin (which had elevated permissions in the form of account management etc).
Honestly I didn't really look into it, just noticed the page didn't load while checking what a tool was for totally unrelated reasons (mysql query timeouts).
The issue that is happening here will not be confined only to target="_blank" links to Striker, but those links are pretty common as the default for toolinfo records generated by Striker for Toolforge tools not marked as web services. Striker is also a place where we can do something about it vs the open internet where we have no control of response headers.
An alternative fix would be to drop the use of target="_blank" for external links entirely. Most browser would have a mechanism for opening a clicked link in a new tab/window that users could use instead.
The docs at https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/noopener say that target="_blank" does the same thing as rel=noopener. In some quick local testing adding rel=noopener explicitly doesn't seem to change anything.
Indeed you are correct, it does not appear to be able to deal with this from the linking side.