Page MenuHomePhabricator

Handle existing #REDIRECT CSS/JS pages
Closed, ResolvedPublic

Description

In T85304#943654, @TTO wrote:

We could at least start by doing something about #REDIRECTs. Either make redirect syntax count as "valid JS" for MediaWiki purposes (although obviously #REDIRECT [[bla]] should never be served up to the user as JS content), or implement an alternative syntax for redirects on JavaScript pages.

I think the cleanest option (from a user perspective) would be:

  • redirects are always "wikitext" content, whether they're in pages named *css/js or not;
  • loading a JS/CSS page which is a redirect actually loads its target.

So the redirects would work consistently.

Event Timeline

Nemo_bis created this task.Dec 25 2014, 9:30 AM
Nemo_bis assigned this task to Krinkle.
Nemo_bis raised the priority of this task from to Normal.
Nemo_bis updated the task description. (Show Details)
Nemo_bis added subscribers: TTO, eranroz, Rillke and 14 others.
  • redirects are always "wikitext" content, whether they're in pages named *css/js or not;

This has to be thought through carefully for security implications: Otherwise it could happen that a malicious user could edit an other user's JS page (because they are redirects and thus not protected by the edituserjs right), and make them valid and malicious JS again.

TheDJ added a comment.Dec 27 2014, 3:18 PM

Also this translates to "Change the ContentModel depending on the Content", which sounds as a terrible idea to me. The ContentModel of a page brings all kinds of side effects with it, and if for EACH action (view, edit, api request), we need to account for the fact that the model can change at any time, then I think we are creating more long term problems than we are solving.

If "redirects should work consistently", then I propose redirects should no longer be wikitext managed as wikitext anymore, but should be 'metadata' of the page, with dedicated UI, instead of wikitext.

Nemo_bis added a comment.EditedDec 27 2014, 9:13 PM

a malicious user could edit an other user's JS page (because they are redirects and thus not protected by the edituserjs right)

Do you mean that css/js subpages *not* corresponding to a user are not protected? I'd call that a bug.

Also this translates to "Change the ContentModel depending on the Content"

That's too general a description. Being a redirect is a page property, it's even in the database.

matmarex set Security to None.
Krinkle removed Krinkle as the assignee of this task.Feb 25 2015, 12:47 AM

Redirects are supported in JavaScript content as of ad9f14d662f9597e. I'm not sure I understand what this task is asking for or why it should block T76204.

Anyone?

Ltrlg added a subscriber: Ltrlg.Sep 16 2015, 8:34 AM
Cyberpower678 closed this task as Resolved.Sep 16 2015, 1:18 PM

I'm marking this as resolved since redirects in the form of JS already exists and works very well.