Let's for a minute forget about my code and look at what we want. From what I gather from the discussion:
* discover extensions available locally, base on some meta-file in each extension's directory. * Have a (web?) UI for listing the available extensions, and enable/disable them. * That would supposedly manipulate a list of active extensions stored in a file (or database table) * That list would have to be read and evaluated for each page request (it should probably be cache in memory, using the object cache or something) * any options the extensions may have would have to be set manually in LocalSettings.php. Since with the new system, extensions wouldn't load until after LocalSettings.php is evaluated, extensions would have to take care not to overwrite options when applying defaults.
This raises some questions
* In case of a web UI, how would it be protected? Would it be inside MediaWiki itself, available to, say, beurocrats? * When an extension is enabled by the UI, some custom script may be run to patch the db. That may require a different db user. * It would be nice to have a way to provide basic options to the extension on install, without having to edit LocalSettings.php
All of the above do not address how to locate and download extensions - which is what the code I wrote mainly does. I personally feel that it's nice to have a repository based installer, like, say, apt or something. So, I wrote something like that. How useful a CLI-based tool for this really is - well, it doesn't hurt to have it, I guess. It would be very convenient, but probably way too dangerous, to allow fetching extensions via a web interface.
In any case, *please* let's establish a repository of tgz bundles of extensions somewhere. It's simply silly to require people to use SVN to get extensions, unless they want bleeding edge. It's also trivial to do for all extensions that have their own directory. A simple script can generate something like this automatically: http://tools.wikimedia.de/~daniel/repository/extensions/
-- Daniel
On 8/3/06, Daniel Kinzler daniel@brightbyte.de wrote:
- In case of a web UI, how would it be protected? Would it be inside
MediaWiki itself, available to, say, beurocrats?
Even if there were to be a Web interface, I don't think bureaucrats will be given privileges to execute arbitrary PHP code anytime soon.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Friday 04 August 2006 00:15, Simetrical wrote:
On 8/3/06, Daniel Kinzler daniel@brightbyte.de wrote:
- In case of a web UI, how would it be protected? Would it be inside
MediaWiki itself, available to, say, beurocrats?
Even if there were to be a Web interface, I don't think bureaucrats will be given privileges to execute arbitrary PHP code anytime soon.
This would be _very_ usefull for small wikis, where the admin could log in, and update/install extensions via an webinterface.
best wishes,
Tels
- -- Signed on Fri Aug 4 01:49:10 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
This email violates U.S. patent #5,546,528 and EU patent EP0689133:
________________________________________ | Header | Body | Attachements | | |--------+ +----------------------| | | ~ ~
On 8/3/06, Tels nospam-abuse@bloodgate.com wrote:
On Friday 04 August 2006 00:15, Simetrical wrote:
Even if there were to be a Web interface, I don't think bureaucrats will be given privileges to execute arbitrary PHP code anytime soon.
This would be _very_ usefull for small wikis, where the admin could log in, and update/install extensions via an webinterface.
Yes, maybe, but not bureaucrats. But I'm not sure a web interface is so critical. How did you install the wiki software to start with without moving the files to the webserver, via FTP or otherwise? If your hosting provider gives you a GUI to add files to your directory from elsewhere, then go ahead and use it. If it doesn't, you'll have to use a command line, just like you did to install MediaWiki in the first place.
A web interface *would* still make things easier for the less technically-inclined, sure. But tying it to the wiki account is very dangerous, because it assumes that there are never going to be any bugs in the user login process that would allow an attacker to gain access. It would be *very bad* to allow arbitrary code to be downloaded and executed with the only security being the MediaWiki account logins; the security procedures just aren't up to it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin,
On Friday 04 August 2006 00:11, Daniel Kinzler wrote:
Let's for a minute forget about my code and look at what we want. From
[snip a bit]
In any case, *please* let's establish a repository of tgz bundles of extensions somewhere. It's simply silly to require people to use SVN to get extensions, unless they want bleeding edge. It's also trivial to do for all extensions that have their own directory. A simple script can generate something like this automatically: http://tools.wikimedia.de/~daniel/repository/extensions/
And it would be way cool if you could use YAML for the meta info, and adopt quite a few things from CPAN. And PLEASE add cryptografic signatures and enforce them (aka warn when not present etc).
Please see here for an example distribution:
http://search.cpan.org/~tels/mediawiki-graph/
There is no need to re-invent the wheel on signing & packagig :)
One could even think of creating an installer that will such a cpan package automatically.
All the best,
Tels
- -- Signed on Fri Aug 4 01:45:36 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
Mediawiki graph-extension: http://bloodgate.com/perl/graph/
wikitech-l@lists.wikimedia.org