fedora-infrastructure

#6650 Mechanism for redirects from wiki pages to docs site
Closed: Fixed Opened by mattdm.

Closed: Fixed
Reopen Issue

We're in the process of moving a lot of user-focused (and contributor-focused) documentation from the wiki to the new docs site https://docs.fedoraproject.org.

Right now, I've been replacing moved pages with stubs like https://fedoraproject.org/wiki/Council, but this is less than ideal for a user experience (and isn't great for our search scores either).

I'd like to be able to redirect with a proper 301 Moved Permanently status. There's a MediaWiki extension which allows external redirects, but that's inherently dangerous. Could we do one of:

  1. Modify the extension (it appears to be quite simple) so that it instead of taking an arbitrary URL, it only works with ^https:\/\/docs\..* (or, I guess, doesn't take URLs at all but pathnames on that site), or
  2. Follow the suggestion of this Stack Exchange answer and use the stock extension restricted to a new "Moved" namespace, to which we restrict to a group of trusted editors we know won't create redirects to spam/scam/malware pages.

What do you think? Other options?

For what it's worth, the extension appears to be very simple. If we went the "modify" route, it'd be 90% stripping off all of the access checking and replacing it with the simple single-site URL validation/constructor.

I made this in about 5 minutes. Not tested. :)

https://github.com/mattdm/FedoraDocsRedirect

@mattdm: your code looks okay-ish, except that
1. We probably want to use a 302 found instead of 301 Permanently Moved, because we can't break a wrong redirect easily.
2. -Scratched-
3. We should make really sure that there are no open redirects.
Edited by puiterwijk

Also, this depends on no headers having been sent yet, so either we need output buffering on (pretty sure we don't), or need to make sure there is no output sent at all before (might be okay, not sure what mediawiki does there).
  1. I think we want 301 for the search engines, because the intention is a permanent move. Even if we decide on some other future location, back to the wiki is unlikely
  2. -
  3. The extension does not pass on the query portion of the URL, which is a little bit of protection. Also, at least currently, docs.fpo is entirely static. Good to note for the future though.

Also, full disclosure: there's a non-zero chance that I made some typo and this isn't valid PHP and/or doesn't work with MediaWiki. Because I am totally just making this up based on the existing example. :)

I took a quick look at your code -- you might want to make sure that the "path" parameter doesn't contain any "@" or ":" characters. In fact, it might be safer to whitelist accepted characters in the path rather than trying to blacklist bad characters.

For example, if path was ":blah@some.other.example.com", the code could very likely redirect the page to some.other.example.com. I haven't tried this personally -- it's just a gut feeling.

@jsmith Good call. I just tested that with a simple CGI script with a location header containing a string with a hostname + that, and it totally causes a redirect to some.other.example.com.

I'm about to board my plane, and I don't actually know PHP, so... patches welcome. :)

Added a basic check. Seems to Work™ in stg.

This is live in prod now.

:poodle:

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.