Last modified: 2010-05-15 15:37:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3395 - Administrator-level configuration (Admin Console) (ie. password resets, etc)
Administrator-level configuration (Admin Console) (ie. password resets, etc)
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.5.x
All All
: Normal enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.marveldatabase.com
:
: 258 5654 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-08 04:39 UTC by Jamie Hari
Modified: 2010-05-15 15:37 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jamie Hari 2005-09-08 04:39:31 UTC
MediaWiki software's post-installation administrative capabilities seems somewhat 
lacking. A small, simple 'super-admin console' with functionality such as password 
resets might be a great convenience. 

Not all wikis have the email function enabled (or working) and hence self-initiated 
password resets might not be possible. The 'admin console', limited access to 'super-
admins' or the like, might be a great place to put many such configuration settings.

Smaller wiki sites are able to 'micro-manage' their site and community, unlike 
Wikipedia that must be mostly automated for convenience sake.
Comment 1 Rob Church 2005-10-15 12:35:39 UTC
I think this would be a good idea, actually; implement a new special page;
Special:Passwordreset. What other functions did you have in mind, however?
Comment 2 Jamie Hari 2005-10-15 22:27:06 UTC
It is a short list of 'new' ideas so far, but I am sure with time I (we) could 
come up with more thoughts.

* Image Renaming
* User Renaming
* Password resets

Also, I thought of bringing existing features currently in LocalSettings.php to an 
interface format. (Again I want to re-iterate this "Admin-Console" should not be 
for "Admins" only "SUPER-Admins") I know there is no such thing as "Super-Admins", 
but again looking at this from a non-wikipedia, small-time-joe perspective this 
will make site administration so much easier.

Examples of configurations currently in LocalSettings.php I propose we add to the 
Admin-Console are:

* Enable/Disable uploads
* Enable/Disable email (& SMTP configuration)
* Enable/Disable Raw HTML
* Enable/Disable User Java/CSS
* Invalidate cache ($wgCacheEpoch)
* The entire group permissions array
* Minimum password length
* etc, etc.

This would of course need to be handled with the utmost concern for security and 
user-authentication as such an Admin-Console in the wrong hands could create havok 
for a wiki...
Comment 3 Rob Church 2005-10-16 13:04:14 UTC
We'd be looking at moving a lot of configuration information to the database in
order to do that, but I do like the idea...sort of. I think I would prefer
special pages to do some of this, e.g. Special:Resetpassword or
Special:Renameuser - the latter already available through an extension.

Does MediaWiki permit one to specify a minimum password length? I wasn't aware
of such a feature.
Comment 4 Jamie Hari 2005-10-16 17:54:28 UTC
Yes. I think I first noticed it in version 1.5.0.
It is called $wgMinimalPasswordLength, on line 1497 of the DefaultSettings.php.
There are a few new fun features... You should browse the DefaultSettings file 
again... (Because the docs sure aren't up to date! (See also, Bug 1))  :)

Anyways...
I am not sure why everyone on this project is so dead-set about making the 
install/configuration more complex than it has to be. I mentioned fixing up the 
install interface and was met with: "That is what the LocalSettings.php file is 
for!"

I am somewhat familiar with php and html and such, but not everyone is. GUI's 
were invented 15 years ago... Shouldn't we take advantage of this wonderful 'new' 
techology? You say it would be a lot of work... I very much agree. Still, 
wouldn't it be worth it for those folks who might use MediaWiki if it were a bit 
easier to setup/maintain?
Comment 5 Brion Vibber 2005-10-16 19:52:56 UTC
In general I'd be leery of putting settings in the database; an SQL-level injection able 
to change certain settings could lead to code execution or other nasties (eg, replacing 
the $wgTexvc command with a rootkit downloader).

Note also that MediaWiki's target audience is large, centrally managed sites that need 
to maintain several hundred wikis off of a single shared, but flexible, configuration.
Comment 6 Jamie Hari 2005-10-16 23:07:25 UTC
Brion,

Point well taken. 

I did realize it would open up several new 'cans of worms' security-wise, but 
maybe only a few non-critical items such as Enable/Disable uploads, Enable/Disable 
email (& SMTP configuration), Invalidate cache ($wgCacheEpoch), etc wouldn't cause 
too much of a security nightmare.

Also, I didn't realize most end-users were large sites (WikiCities, etc), I 
figured, going forward, more and more 'small-fries' would take advantage of this 
AMAZING software...
Comment 7 Rob Church 2005-10-17 13:03:34 UTC
I'd say permitting uploads is a "critical" item, myself.
Comment 8 Rowan Collins [IMSoP] 2005-12-13 20:29:08 UTC
It occurred to me ("a blinding flash of the obvious", as my dad would say) in
pondering bug 4262 that there is a way to combine the flexibility and efficiency
of a static LocalSettings.php file with the ease-of-use and automation of an
admin interface: create an interface which *generates* the PHP file. This way,
no settings need to be in the database, and the admin interface needn't even
have direct write access to the settings (though the option to enable that could
be included, with big red security warnings).

Of course, all sorts of systems already do this - think of the unified
configuration tools in Linux distributions ("dpkg-reconfigure mediawiki" :p),
for instance; in fact, the installer already lets you set some things on an HTML
form which then end up in LocalSettings.php. Since shell access is far from
guaranteed, this would probably be a web-based interface, but the central point
is the same: a form would be presented with a number of commonly-used
configuration options; toggling these would perform various sanity checks, like
checking for conflicting settings, and set one or more options, possibly based
on yet other options, or even database content. 

By running as part of MediaWiki itself, it could know the current state of
settings simply by executing the initialisation scripts itself. And when it
changed options, it could set those variables in its own environment as well as
in its prospective output [so they'd always be consistent, even if you changed
several in a session before clicking "save"]. To actually output the string, it
would presumably grep for the current string for that setting, delete or comment
it, and add an adjacent line with the new setting; new settings could either go
at the end of the file or in specially marked sections (e.g. "/* ==Image
settings== */")

The result would be a modified LocalSettings.php, either output to the user, or
saved to the installation directory (as, say, "LocalSettings.auto"). Somebody
with real server access would then copy it over the existing file, and hey
presto! And, like I say, if someone really trusted the security of the config
interface, they could grant it [manually, on the server] the ability to
overwrite the file directly (after making a backup). True, it would still
require manual intervention on the server, but it would make the configuration
itself much more self-documented...

So, other than "why don't you code it then, clever-clogs?", what are people's
thoughts?
Comment 9 Rob Church 2005-12-17 02:17:47 UTC
*** Bug 258 has been marked as a duplicate of this bug. ***
Comment 10 Rob Church 2005-12-17 02:18:20 UTC
Comment merged over from bug 258:

"If I choose the invitation-only, closed shop setting in LocalSettings.php, I
have to manually edit $wgWhitelistRead in the file to add new pages for public
viewing. I don't always have shell access to do it and that's a bother anyway.
It would be nice if, as a sysop, I could add or remove a page from the whitelist
while viewing it on my wiki, just like I can protect it."
Comment 11 Jamie Hari 2006-02-06 00:03:22 UTC
Bug 4886 talks about intelligent (automated) server-side intra-wiki link 
rendering... The user-defined list of 'linkable' words could be easily maintained 
from this proposed admin-console.

Also, I like the talk of maintaining such items as the filetype whitelist and 
user/group permissions from the console.

Any new thoughts on this?
Comment 12 Rowan Collins [IMSoP] 2006-02-07 18:03:52 UTC
(In reply to comment #11)
> Bug 4886 talks about intelligent (automated) server-side intra-wiki link 
> rendering... The user-defined list of 'linkable' words could be easily maintained 
> from this proposed admin-console.

Well, there's no particular need for that to be done through a special "admin
console" - whoever implements the "wikifier" can store the word list in the
database, and have a normal Special: page for editting it (with appropriate
permissions required). If it *did* end up in LocalSettings.php, though, any
admin interface would easily be able to accomodate it (or it would the way I was
thinking of it). 

Unfortunately, I just got a full-time job, so my plans for world domination /
MediaWiki coding may be more on hold than usual.
Comment 13 Jamie Hari 2006-02-24 05:59:32 UTC
I thought of a few more settings that could go in the 'admin console'.

How about defaults for things like:

How many images to show in categories (currently at 200, could change to
20/50/100/200)
How many changes to show in recent changes (for not logged in users)
Maximum size for image uploads (warning size as well)

Also, an easier place for modifying MediaWiki:Sidebar and MediaWiki:Sitenotice...
(not that I didn't LOVE the new sidebar interface!)

I know I am stretching to bring everything into an interface, but remember,
folks who Administrate websites are often not php/mysql programmers. If
MediaWiki is intended for use by large organizations, shouldn't there be a great
deal of separation from  code/files to site administration? 

Not too many site admins I know (myself included) are willing to delve into
lines of code, (nor adept enough) just to 'invalidate cache ($wgCacheEpoch)'.

Brion / Rob Church:
Can I get some additional thoughts by you guys on this?
Comment 14 Rob Church 2006-04-19 20:58:16 UTC
*** Bug 5654 has been marked as a duplicate of this bug. ***
Comment 15 Chad H. 2008-09-22 19:11:17 UTC
Between various extensions (PasswordReset, RenameUser and Configure), I think all the things this bug is asking for have been done. Closing as FIXED.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links