WikiWindow will allow each user to interact with MeatballWiki (or any other wiki) through whatever wiki frontend they wish. It won’t require any server-side changes. It isn’t done yet, but the WikiGateway part is functional.
See InterWikiSoftware:WikiWindow for more discussion; the following is excerpted from there.
Let’s say that you want to view the page MeatBall:SandBox through OddMuse. Let’s say there was an OddMuse MeatballWiki window set up at http://interwiki.sourceforge.net/cgi-bin/mbOddMuse.cgi. You point your browser at the page http://interwiki.sourceforge.net/cgi-bin/mbOddMuse.cgi?SandBox.
:The OddMuse CGI script at mbOddMuse.cgi has been modified so that instead of looking into its native PageDatabase for the requested page, it makes an XmlRpcToWiki request to a WikiGateway, which let’s say resides at http://usemod.com/cgi-bin/mbWikiGateway.cgi.
::The script mbWikiGateway.cgi accepts the XmlRpcToWiki request and emits a normal HTTP page browse request to http://usemod.com/cgi-bin/mb.pl. mb.pl sees this as just another user asking for a page, and sends the page to mbWikiGateway.cgi.
:mbWikiGateway.cgi then replies to the XmlRpcToWiki request from mbOddMuse.cgi.
Finally, mbOddMuse.cgi acts as if it got the page from it’s own PageDatabase, and displays it to you.
The flow of data is:
You can edit the page through the OddMuse window, too. It works similarly.
Hmm, I guess you could say that a wiki window is just a TransClusion with no content of it’s own. Note that this is a TransClusion in which you can edit the source, though; people using the window are acting as MeatballWiki community members, rather than members of a different community which has transcluded some pages.
Right now I intend to bypass the markup conversion problem by just having the “real” wiki do the rendering of wiki markup into HTML rather than the frontend wiki; i.e. a UseMod frontend would be have &WikiToHTML?? replaced with a call to a WikiGateway.
Eventually I want to add markup conversion routines to WikiGateway; i.e. you would do $usemodPage = WikiGateway:MoinMoinToUseMod?($moinMoinPage), etc. This is a WorseIsBetter approach as compared to waiting for a WikiMarkupStandard.
A web service using WikiGateway would introduce a number of problems, mostly security-related. Suach a web service essentially becomes a web proxy specialized to access wiki – and an OpenProxy at that! There is a reason why the MeatBall wiki does open proxy scanning and bans such addresses (at least it used to do that).
So, a web service providing consistent user interface for multiple wikis would need a number of anti-abuse mechanisms – and at the same time can’t really use the anti-abuse mechanisms of the wikis it communicates with. Then again, most wikis already have a web interface, so the win is not reall that big.
hmm…it is deifnitely part of what i was thinking about… Thanks!
I think that authorization has to be part of the wiki server. WikiGateway’s job should be, in my opinion, only to provide an API that allows bots to interact with the server’s authorization system and submit their credentials.
I don’t expect that many wikis will allow bots to create accounts or edit pages without an account (I would expect that wikis will require the user to pass a CAPTCHA to do these things). But I hope that wiki servers will provide a way for trusted users to be granted special passwords or other credentials that allow them to run client-side bots.
If some wikis allow users to edit pages without ever being validated first (validation meaning either by passing a CAPTCHA or by being certified as trusted by other community members) then it’s only a matter of time before spammers use bots to attack those sites, regardless of whether WikiGateway exists or not.
Many wikis don’t have accounts and passwords, and rely on MeatBall:SoftSecurity. For them, a WikiWindow stripping the information about the user’s host is effectively an anonymizer, rendering the most brutal, “last chance” soft security techniques useless.
Hmm, I see. So you’re concerned about wiki engines which don’t implement much authentication but which do log IP, and in which the community uses that logged IP. A WikiWindow obscures the IP of the poster. So in this case, the WikiWindow isn’t just the same as some spammer writing a script, it is actually worse. Do I understand correctly?
My first impression is that this is indeed a problem. I hadn’t thought about this problem before, thanks for pointing it out. In the long term, I expect that bot networks will make IP address logging useless for protecting against attack. In the long term, I would expect that wikis would implement authentication schemes and that people posting through a WikiWindow would be able to, and be required to, authenticate through the WikiWindow first. But in the midterm, knowing the IP does seem to help, and in the midterm, many wikis don’t seem to do robust authentication.
One thing that could be done is for the WikiWindow itself to keep its own log of IP addresses from which writes originated, and to make this public (or at least available to everyone who has access to that sort of info on the target wiki). And to be sure to let the admins of the target window enter IP address bans on the WikiWindow or what have you (better: if the list of banned addresses on the target wiki is public, the WikiWindow could just automatically enforce that list on the window). But this doesn’t interoperate with whatever convenient mechanisms the target wiki has for easily looking at the IP addresses right there in the page history, so if those IPs are used frequently, this puts a burden on the users.
I would be very sad if all the wikis were forced to devise some kind of authentication/authorization mechanism – it’s like seeing plains and fields being fenced. I don’t want Internet that is all locked up.
As for collecting the logs or exposing the IP number or host name in other ways, we must remember that:
On the other hand, WikiWindow could be a good way to share blacklists between wikis.