[MediaWiki-l] Third-Party Users Wish List - Does Anyone Know of Existing/Experimental Solutions?

Yury Katkov katkov.juriy at gmail.com
Mon Jan 28 16:26:23 UTC 2013


Hi Maria! Let me clarify the situation about access control. There are
several dozens of ways (!) to get the information of a wiki page - and
that's only in the core! And what's about extensions? Each of them is
responsible for access control by itself, therefore each of them provides
another couple of ways to access any content you want. I'm pretty sure that
now it's impossible to create a reliable (the one you can store your credit
card number) Access Control extension without hacking and patching the core
- and aftyer that some ways to get the data still remains. The WMF position
here is the following: "if you need access control, if you want to hide
some stuff from some groups of users - get out of here and choose another
wiki engine." If you're asking us about our problems - here is one of the
most depressing problem of all.

So when the 3rd parties ask about supporting the access control
restrictions they basically ask WMF to think again about this dogma that
"MediaWiki was born to be open and this openness will remain forever". We
want to store personal and sensitive data in wikis, create systems with
premium accounts, we want to restrict the read access to some articles and
we want to be sure that it's impossible to get access to these data neither
from client code, nor from extensions.
I think I've expressed everyone's thoughts, correct me if I'm wrong.

Very truly yours,
Yury Katkov, WikiVote!
28.01.2013 16:19 пользователь "Ingo Malchow" <imalchow at kde.org> написал:

> Am Montag, 28. Januar 2013, 14:07:45 schrieb Maria Miteva:
> > Hi everyone,
> >
> > I have been talking to some third-party users trying to learn more about
> > what they would like to see happening in MediaWiki in the near future.
> Here
> > is a list of the things on the wish list, with the ones on top being more
> > popular.
> >
> <snip>
> > 10. Easy way of gracefully retiring old tags (e.g. Google Maps extension
> is
> > no longer supported, replaced with Maps which has different tags)
>
> Just to have it mentioned, the replace text extension
> (https://www.mediawiki.org/wiki/Extension:Replace_Text ) makes it a sharm
> for
> admins to bunch-replace outdated tags with new ones. We had that problem
> once
> with one of the syntaxhighlighting extensions and a switch to the new one.
>
> >
> > 11. Update to the documentation about creating a simple extension that is
> > XSS safe.
> >
> > 12. Mobile version for website that turns with MediaWiki   - this is in
> > progress
> > http://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core
> >
> > 13. MediaWiki Core API.
> > "Not the HTTP-API but the set of PHP classes in the core that are less
> > likely to change in the next version. Core developers to think about
> > MediaWiki as framework with programming interfaces for extension
> > developers. All the changes in those interfaces have to be calm, with
> slow
> > deprecation. A role model for that is Python compiler."
> >
> > Sorry for the long email and thank you if you made it here. The
> alternative
> > was to send many emails and I thought that would be too spammy :)  More
> to
> > come soon !
> >
> > Mariya
>
> Cheerio,
> Ingo Malchow
> --
> (neverendingo)
> KDE Community Working Group, KDE User Working Group
> KDE Community Forums Administrator
> New to KDE Software? - get help from http://userbase.kde.org or ask
> questions
> on http://forum.kde.org
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>


More information about the MediaWiki-l mailing list