Issue:Option to only run DPL from protected pages

Description:	Protect your wiki from DPL abuse. E.g. "$wgProtectedDPL" as option to let DPL run only from protected pages.
Extension / Version:	DPL   /   ?
Type / Status:	Change Request   /   open / mostly answered

Problem

Note: I talk about an option, not a must.
Some wiki admins may not like the idea that other users can run DPL from any page. E.g. I'm paranoid, somebody copies all my content, so I disabled all Export features etc.

An option to give the full control to the admin is by letting DPL code only run from protected pages. Extension:SecureHTML uses it and it is so simple & safe at the same time. Advantages with "$wgProtectedDPL":

• To protect a page you have to be an administrator, i.e.
• Normal users can't create pages with DPL code
• Normal users can't manipulate existing DPL code, because they can't edit the page. This is also possible without this new feature but with "$wgProtectedDPL" they simply can't do things the admin didn't allow with his DPL functions.
• Normal users can't create or manipulate DPL code. They can include a protected DPL page or a normal page which itself includes DPL code, but then? No abuse :)

It may not seem to be important for you but surely for other wikis with sensible data.

Reply

What would one have to do to add an option which allows DPL only to be run from protected pages? Gero 21:56, 30 April 2009 (UTC)

Dunno exactly, that's why i request it here. But Extension:SecureHTML uses it:

	/**
	 * Verifies if the target page is protected for 'edit'
	 */
	protected function getAndCheckTitle( &$page_name, &$title )
	{
		$title = Title::newFromText( $page_name );
		if (!is_object( $title ))
			return false;
		
		// if the title does not exist,
		// then the caller will probably generate a broken link
		if ( !$title->exists() )
			return null;
		
		return $title->isProtected( 'edit' );
	}

--Subfader 02:05, 1 May 2009 (UTC)

In fact it was quit easy to do; Release 1.7.7 of DPL contains the new feature. Gero 07:02, 1 May 2009 (UTC)

Thanks a lot. Will test :) --Subfader 14:29, 1 May 2009 (UTC)

Works so far. Returns '1' if the page is not protected. Maybe this could be specified but that's not essential.

But protected pages can't be included on unprotected pages? E.g. when you use dpl code on a protected template, it should be possible to include in on unprotected pages.

A solution or further feature might be to define an array of Page titles (which are still protected to work at all) which can be included on unprotected pages. I guess it's an easy addition to the code. This would make it secure but flexible. --Subfader 16:34, 1 May 2009 (UTC)

The thing is I wrote templates which users can add to their user pages to display their latest edited pages, uploaded files etc. But with the protection enabled in DPL it's not possible. --Subfader 15:08, 5 July 2009 (UTC)

Reply

I would like to add a feature which allows DPL to execute its query if the DPL statement is part of a protected page. This would be a good solution, I think. But I can find no way how an extension function (which is called by wfRunHooks) can find out, from which source it comes. The parser PreProcessor does not keep even keep that knowledge as far as I could see when I dived into MW parser source code. Consequently parser->getTitle() always returns the title of the top page.

Do you know if an extension can find out where the source line invoking it comes from? Or do you know a guru who knows?

Even the brute force approach of having a special (protected) page which contains names of "allowed" templates cannot be implemented if the DPL extension can´t find out where its own calling codel line comes from ...

Gero 21:20, 5 July 2009 (UTC)