McDrake Wiki

opmerkingen, vragen, klachten, suggesties

Berichtdoor Appie Aap » zo aug 08, 2010 9:33 pm

Daniel73 schreef:Momenteel is de McDrake Wiki weer gevandaliseerd door spammers:
http://wiki.mcdrake.nl/index.php?title=Special:RecentChanges
Het gaat om een spammer met IP-adres en/of username "94.102.51.196". En om spammers met usernames "AssaCom" en "EmmaWatson55‎".

Ik probeer als Adniel de bijdragen en de accounts van deze spammers te verwijderen, maar hoe moet ik dat doen?

Accounts kunnen volgens MediaWiki niet worden verwijderd, maar ze kunnen wel voor altijd worden geblokkeerd (zie hier)Dit is erg irritant, want dit betekent dat het aantal accounts oneindig kan blijven oplopen.
Het IP-adres van de gebruiker "EmmaWatson55" is nu geblokkeerd, evenals het IP-adres "94.102.51.196".

Ik heb om het spammen tegen te gaan de belangrijkste pagina's als 'protected' ingesteld. Helaas gaan de spammers ook gewoon door op de talk-pagina's. Het is dus beter om de pagina's maar allemaal direct te 'protecten'. Maar hoe moet dat? Ik heb het even opgezocht en ik kwam op deze pagina:

http://www.mediawiki.org/wiki/Extension_talk:ProtectSource#To_protect_all_pages.

Volgens deze pagina moet er in het bestand 'ProtectSource.php' het één en ander worden aangepast. Ik hier geen toegang toe, maar misschien hebben jullie (Caspar en Daniël73) er wat aan.
Avatar gebruiker
Appie Aap
Liefhebber
Member
 
Berichten: 1069
Geregistreerd: zo nov 22, 2009 1:15 am
Woonplaats: Duckstad

Berichtdoor Daniel73 » ma aug 09, 2010 7:52 pm

Inmiddels meen ik een pagina gevonden te hebben waarop alle(?) logs van McDrake Wiki te bekijken zijn:
http://wiki.mcdrake.nl/index.php?title=Special:Log&user=%2A
Als ik zonder iets in te vullen druken op "Go", krijg ik een lijst van veranderingen die veel verder teruggaat dan op de pagina"Recent changes". De vroegste datum is er 6 maart 2010, waarop het account van Caspar is aangemaakt.

De mysterieuze "Admin" heeft op die datum het volgende gedaan: "changed group membership for User:Caspar from (none) to Administrators and Bureaucrats"
De "Admin" wordt dus bediend door Caspar. Maar hoe?

Appie Aap schreef:Accounts kunnen volgens MediaWiki niet worden verwijderd, maar ze kunnen wel voor altijd worden geblokkeerd (zie hier)Dit is erg irritant, want dit betekent dat het aantal accounts oneindig kan blijven oplopen.
Het IP-adres van de gebruiker "EmmaWatson55" is nu geblokkeerd, evenals het IP-adres "94.102.51.196".

Ging het bij de laatste om een accountnaam of echt om een IP-adres? Inloggen met alleen een IP-adres is toch uitgezet?
Het blokkeren van IP-adressen vind ik bezwaarlijk omdat het adres vervalst kan zijn. Op die manier blokkeer je een IP-adres van iemand die onschuldig is, terwijl de spammer doodleuk overstapt op het volgende valse adres.

Kunnen accounts niet worden verwijderd? Wat is dit voor onzin van MediaWiki? :O
Ik begrijp dat het wel mogelijk is om usernames te "mergen" (samenvoegen) en daarna het lege account te verwijderen:
http://www.mediawiki.org/wiki/Extension:User_Merge_and_Delete
Op die manier zouden accounts van spammers kunnen worden samengevoegd in een neutraal account, waarna de oude accounts kunnen worden verwijderd. Als ik het goed begrijp. Maar dat is wel een extra tussenstap die moet worden uitgevoerd om een ongewenste indringer te verwijderen.

Het lijkt wel alsof software zoals PunBB en MediaWiki meer gemaakt is voor het gemak van spammers dan voor het gemak van beheerders. Een spammer kan eenvoudig een wiki vandaliseren en de beheerder moet maar een studie gaan volgen hoe dat tegen te gaan.

Een FAQ voor MediaWiki:
http://www.mediawiki.org/wiki/Manual:FAQ

Appie Aap schreef:Ik heb om het spammen tegen te gaan de belangrijkste pagina's als 'protected' ingesteld. Helaas gaan de spammers ook gewoon door op de talk-pagina's. Het is dus beter om de pagina's maar allemaal direct te 'protecten'. Maar hoe moet dat? Ik heb het even opgezocht en ik kwam op deze pagina:

http://www.mediawiki.org/wiki/Extension_talk:ProtectSource#To_protect_all_pages.

Volgens deze pagina moet er in het bestand 'ProtectSource.php' het één en ander worden aangepast. Ik hier geen toegang toe, maar misschien hebben jullie (Caspar en Daniël73) er wat aan.

Volgens mij heeft Caspar het wachtwoord voor de wiki-directory. Als jij om kunt gaan met de server en het aanpassen van zulke bestanden, mag je wat mij betreft dat wachtwoord hebben. Is dat een werkbare situatie?
Maar wat als meerdere personen tegelijk inloggen met dat account? Ik weet niet of de provider meerdere FTP-accounts biedt voor een subdirectory. Het lijkt van wel, maar ik zou het voor de zekerheid moeten navragen.
Wat vindt Caspar? Mogen meerdere personen, waaronder ik, aanpassingen maken in zulke bestanden? Is dat handig of is het vragen om problemen?

Volgens de pagina "Recent changes" zijn de gespamde pagina's blanco gemaakt. Maar hierdoor is de spam nog steeds onderdeel van de wiki. Mijn indruk is dat een beheerder de mogelijkheid heeft om de pagina's echt te deleten.
Op de pagina User:EmmaWatson55 zie ik als beheerder een delete-knop. Als ik daarop druk krijg ik als medeling: "You are about to delete a page along with all of its history. Please confirm that you intend to do this, that you understand the consequences, and that you are doing this in accordance with the policy."
Na het deleten kan ik als beheerder (Adniel) de inhoud nog wel terughalen, maar niet als bezoeker (Daniel73).
Bij spam heeft deleten mijn voorkeur. Anders zit je alsnog die rommel te bewaren.

Ook pagina Help:Editing heb ik op bovenstaande manier gedelete. Maar ditmaal heb ik het "reason"-veld blanco gemaakt, waardoor er geen melding "content was: ..." in de lijst van recent changes komt te staan. Ik stel voor om de spam voortaan zo te verwijderen.


Ik wil me best verdiepen in MediaWiki. Leuk zelfs. Maar ik vraag me wel af waar het studeren ophoudt. Ik zoek software om o.m. Disney-gerelateerd materiaal online te kunnen plaatsen, maar kom door de software niet aan dat materiaal toe. Dat is tegenstrijdig. Logischerwijs kan ik dan evengoed helemaal niets doen, als het materiaal uiteindelijk toch maar in de kast blijft liggen.
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Daniel73 » ma aug 09, 2010 7:55 pm

Daniel73 schreef:Als ik zonder iets in te vullen druken op "Go"

Als ik zonder iets in te vullen druk op "Go"...
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Daniel73 » ma aug 09, 2010 9:34 pm

Uit het topic 'Toekomst mcdrake.':
2010-08-09 21:02:54, Fuzzy schreef:Geen idee of het aan mij ligt maar als ik zoek bij Google op mediawiki spam is de eerste hit die ik krijg deze:
http://www.mediawiki.org/wiki/Manual:Combating_spam

Hierin staan een heel aantal oplossingen die gedaan kunnen worden tegen spam om maar een voorbeeld te noemen Captcha's (http://www.mediawiki.org/wiki/Extension:ConfirmEdit), je weet wel die dingen die je nooit kunt lezen en 10 keer fout typt.
Het mag dan lastig zijn voor de gewone gebruikers maar je weert er wel de spambots mee. Ik heb het even snel doorgelezen en het woord duidelijk uitgelegd hoe dit te installeren is, ik ga er vanuit dat dit wel moet lukken.
Er staat netjes aangegeven hoe je de extension kunt installeren bij mediawiki en welke regels in de .php configuratie bestanden moeten worden gewijzigd/toegevoegd.

Ook is het mogelijk om bepaalde users in groepen te doen bijvoorbeeld groep editors en deze toe te voegen aan de configuratie files zodat deze niet telkens de captcha's zien.

Ook zijn er extensies te vinden om bekende spambots te blacklisten op ip, ik weet niet of dit werkt maar ik ga er vanuit dat je hiermee ook al een heleboel spambots uitschakeld.
Het gaat om de volgende links:
Informatie over blacklist: http://www.mediawiki.org/wiki/Spam_Blacklist
Lijst met bekende hosts/ips van spammers: http://meta.wikimedia.org/wiki/Spam_blacklist

bron: http://bb.mcdrake.nl/neddisney/viewtopic.php?p=27040#p27040
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Daniel73 » ma aug 09, 2010 9:51 pm

Fuzzy schreef:Geen idee of het aan mij ligt maar als ik zoek bij Google op mediawiki spam is de eerste hit die ik krijg deze:
http://www.mediawiki.org/wiki/Manual:Combating_spam

Ik had gisteren ook al gauw wat informatie gevonden. Maar het lezen, begrijpen en toepassen, daar zit de grote moeite. Daar ben ik minstens een uur zoet mee. Als ik in dat uur eigenlijk hoopte aan de wiki te kunnen bijdragen over (bijvoorbeeld) Disney-gerelateerde onderwerpen, kun je misschien mijn ergernis begrijpen. En telkens een uur kwijt zijn, maakt vele uren. Tijd die ik liever besteed had aan mijn hobby's.

Aangezien MediaWiki een aantrekkelijk doel is voor spammers, begrijp ik niet waarom men elke beheerder zelfstandig laat zoeken naar oplossingen. Die oplossingen hadden reeds in het pakket kunnen zitten. (Men zou dan zelf kunnen aanvinken wat men in de installatie wil meenemen.)
Er zijn nu minstens drie personen aan het discussiëren over het oplossen van een standaard-probleem!

Even dit zoeken, even dat zoeken, voor je het weet is de dag voorbij. Deed ik alleen de Mediawiki, dan was het zoeken zo gebeurd. Maar er moet ondertussen ook nog gezocht worden naar oplossingen voor de spamgevoelige forumboards. Stuk voor stuk wielen die telkens opnieuw worden uitgevonden, om een algemeen probleem op te lossen. Ik zou me rotlachen als ik spammer was.

De Mediawiki-gebruiksaanwijzing moedigt aan om spam te bestrijden door ook op andermans wiki's de spam te verwijderen. Maar wat doen de Mediawiki-makers zelf tegen het probleem? Door Mediawiki standaard af te leveren als een paradijs voor spammers, zoals nu de McDrake Wiki, levert men zelf een enorme bijdrage aan platforms voor spammers.
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Appie Aap » ma aug 09, 2010 10:11 pm

Daniel73 schreef:Inmiddels meen ik een pagina gevonden te hebben waarop alle(?) logs van McDrake Wiki te bekijken zijn:
http://wiki.mcdrake.nl/index.php?title=Special:Log&user=%2A
Als ik zonder iets in te vullen druken op "Go", krijg ik een lijst van veranderingen die veel verder teruggaat dan op de pagina"Recent changes". De vroegste datum is er 6 maart 2010, waarop het account van Caspar is aangemaakt.

Dat is handig. Moet die link voor de duidelijkheid op de hoofdpagina (dat we hem niet vergeten tussen alle posts?).

Daniel73 schreef:
Appie Aap schreef:Accounts kunnen volgens MediaWiki niet worden verwijderd, maar ze kunnen wel voor altijd worden geblokkeerd (zie hier)Dit is erg irritant, want dit betekent dat het aantal accounts oneindig kan blijven oplopen.
Het IP-adres van de gebruiker "EmmaWatson55" is nu geblokkeerd, evenals het IP-adres "94.102.51.196".

Ging het bij de laatste om een accountnaam of echt om een IP-adres? Inloggen met alleen een IP-adres is toch uitgezet?

Bij de laatste ging het om een IP-adres. Deze was namelijk aan het spammen op een pagina die niet beschermd werd (een talk-page volgens mij). Daarom lijkt het mij beter om een stukje code toe te voegen die alle pagina's beschermt (zie vorige post).

Daniel73 schreef:Het blokkeren van IP-adressen vind ik bezwaarlijk omdat het adres vervalst kan zijn. Op die manier blokkeer je een IP-adres van iemand die onschuldig is, terwijl de spammer doodleuk overstapt op het volgende valse adres.

Ik wist niet dat spammers ook konden spammen op een al bestaand IP-adres (ik heb wat betreft IP-adressen niet erg veel verstand :| ). Ik kan de blokkades altijd opheffen, zeker wanneer alle pagina's op 'protected' staan. Dan kunnen niet-geregistreerde gebruikers niets bewerken.
Accounts blokkeren gaat op Username. Er is ook nog een extra optie die kan worden aangevinkt:
"Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from"
Misschien moet ik dat in het vervolg niet meer doen?

Daniel73 schreef:Kunnen accounts niet worden verwijderd? Wat is dit voor onzin van MediaWiki? :O
Ik begrijp dat het wel mogelijk is om usernames te "mergen" (samenvoegen) en daarna het lege account te verwijderen:
http://www.mediawiki.org/wiki/Extension:User_Merge_and_Delete
Op die manier zouden accounts van spammers kunnen worden samengevoegd in een neutraal account, waarna de oude accounts kunnen worden verwijderd. Als ik het goed begrijp. Maar dat is wel een extra tussenstap die moet worden uitgevoerd om een ongewenste indringer te verwijderen.

Dat is goed gevonden! Raar alleen dat het niet wat minder omslachtig kan.

Daniel73 schreef:
Appie Aap schreef:Ik heb om het spammen tegen te gaan de belangrijkste pagina's als 'protected' ingesteld. Helaas gaan de spammers ook gewoon door op de talk-pagina's. Het is dus beter om de pagina's maar allemaal direct te 'protecten'. Maar hoe moet dat? Ik heb het even opgezocht en ik kwam op deze pagina:

http://www.mediawiki.org/wiki/Extension_talk:ProtectSource#To_protect_all_pages.

Volgens deze pagina moet er in het bestand 'ProtectSource.php' het één en ander worden aangepast. Ik hier geen toegang toe, maar misschien hebben jullie (Caspar en Daniël73) er wat aan.

Volgens mij heeft Caspar het wachtwoord voor de wiki-directory. Als jij om kunt gaan met de server en het aanpassen van zulke bestanden, mag je wat mij betreft dat wachtwoord hebben. Is dat een werkbare situatie?
Maar wat als meerdere personen tegelijk inloggen met dat account? Ik weet niet of de provider meerdere FTP-accounts biedt voor een subdirectory. Het lijkt van wel, maar ik zou het voor de zekerheid moeten navragen.
Wat vindt Caspar? Mogen meerdere personen, waaronder ik, aanpassingen maken in zulke bestanden? Is dat handig of is het vragen om problemen?

Tja, ik heb eigenlijk totaal geen ervaring met het beheren van servers en bijbehorende bestanden. Ik zou het wel kunnen proberen, maar ik wil niet het risico lopen dat er iets helemaal fout gaat, terwijl er geen back-up of iets dergelijks is gemaakt. In dit licht lijkt het me geen goed idee.
Neemt niet weg dat ik het graag wil proberen. Als ik de hele tijd met oplossingen aankom die anderen moeten uitvoeren, voel ik me ook weer wat bezwaard. En een stukje code veranderen lijkt me ook niet zo heel moeilijk.

Daniel73 schreef:Volgens de pagina "Recent changes" zijn de gespamde pagina's blanco gemaakt. Maar hierdoor is de spam nog steeds onderdeel van de wiki. Mijn indruk is dat een beheerder de mogelijkheid heeft om de pagina's echt te deleten.
Op de pagina User:EmmaWatson55 zie ik als beheerder een delete-knop. Als ik daarop druk krijg ik als medeling: "You are about to delete a page along with all of its history. Please confirm that you intend to do this, that you understand the consequences, and that you are doing this in accordance with the policy."
Na het deleten kan ik als beheerder (Adniel) de inhoud nog wel terughalen, maar niet als bezoeker (Daniel73).
Bij spam heeft deleten mijn voorkeur. Anders zit je alsnog die rommel te bewaren.

Ook pagina Help:Editing heb ik op bovenstaande manier gedelete. Maar ditmaal heb ik het "reason"-veld blanco gemaakt, waardoor er geen melding "content was: ..." in de lijst van recent changes komt te staan. Ik stel voor om de spam voortaan zo te verwijderen.

Ok, dat is uitstekend (ik hoop dat ik het niet vergeet). :)
Avatar gebruiker
Appie Aap
Liefhebber
Member
 
Berichten: 1069
Geregistreerd: zo nov 22, 2009 1:15 am
Woonplaats: Duckstad

Berichtdoor Caspar » di aug 10, 2010 11:58 am

Tja, spam is voor alle beheerders een verschrikkelijk probleem. Niet alleen MediaWiki en PunBB hebben daar last van hoor, alle forumsoftware en Wordpress bijvoorbeeld ook. Ik krijg dagelijks op Beautiful Freaks tientallen spamberichten, maar via een plugin worden die automatisch herkend en geblokkeerd. Probleem van mij is nou juist dat Wordpress iets te streng controleert en berichten van Daniel soms ook als spam aanziet. Wat McDrake dus nodig heeft is bijvoorbeeld een captcha. Voor het nieuwe forum gaat dat helemaal goedkomen, de wiki wordt wat moeilijker.

Want als ik eerlijk ben, bevalt de MediaWiki-software niet echt. Alles is zo onzettend ingewikkeld en onhandig. Voor de meest simpele instellingen moet je al in de broncode gaan zitten wijzigen, in plaats van dat er een simpel admin-panel is, waar je functies kan in- en uitschakelen. Ook voor gebruikers is het vervelend om iets op de wiki te posten; simpele tekst met HTML-opmaak gaat nog wel, maar zelfs met plaatjes wordt het al moeilijk. Ik heb, als de beheerder-in-functie van de wiki, totaal geen verstand van de software, en ook geen zin om me daar goed in te gaan verdiepen voordat ik echt wat ermee kan. Ik had gehoopt dat zulke software die door veel mensen gebruikt wordt en ook door grote instanties (Wikipedia) net als Wordpress of willekeurige forumsoftware intuitief en zonder veel moeite zou werken, maar ik heb me vergist. Eigenlijk wil ik op deze manier niet verder werken aan de wiki, omdat ik me dan eerst moet gaan verdiepen voor ik vanalles voor elkaar kan krijgen.
Caspar
McDrake's Willie Wortel
Member
 
Berichten: 799
Geregistreerd: ma jan 01, 2007 6:38 pm

Berichtdoor Daniel73 » di aug 10, 2010 3:24 pm

Vorige week is op 3 augustus 2010 een update uitgevoerd via Installatron. Die update is uitgevoerd door de provider, omdat ik een foutmelding kreeg. Er bleek een bug te zijn.
Zijn door deze update misschien instellingen gewijzigd? Ik kan pagina's bewerken ZONDER in te loggen!!


Over spam:
Inmiddels heb ik een moedige poging gewaagd om "version r62678 of the ConfirmEdit extension for MediaWiki 1.16.x" te installeren. Deze wordt op pagina Special:Version herkend.

Maar ik zie het niet werken. Ik kan zonder in te loggen, pagina's wijzigen. Niks dat me tegenhoudt.

Dus ik kijken op Extension_talk:ConfirmEdit
Daar kom ik onder meer het volgende vraag en antwoord tegen:
Doesn't work

Hi, i installed confirmedit on my debian lenny server. But it doesn't work for me. No captcha showed. My wiki version: MediaWiki 1.15.1 PHP 5.2.6-1+lenny3 (apache2handler) MySQL 5.0.51a-24+lenny1-log In version special page, i don't find any ConfirmEdit entry.

Have you read the installation instructions? If you don't see it on Special:Version, it's not installed properly. Max Semenik 09:06, 30 November 2009 (UTC)


bron: http://www.mediawiki.org/wiki/Extension_talk:ConfirmEdit#Doesn.27t_work_2

Men stelt slechts een wedervraag: "Heb je de gebruiksaanwijzing gelezen?" En zegt vervolgens dat wanneer de extensie niet te zien is op de pagina 'Special:Version', dat de installatie dan niet goed is. Ja, en dan?
De vraagsteller is gedetailleerd. Hij weet überhaupt wat voor soort server hij heeft. Heeft zelfs de "Special:Version"-pagina bekeken. (Daar had ik niet aan gedacht.) Maar hij krijgt geen inhoudelijk antwoord. Ik lees: "Hoepel op!"

Welnu, op de McDrake Wiki is de extensie wel te zien op Special:Version. Dus wat nu? Ik begrijp geen moer van die gebruiksaanwijzing.

Na het kiezen van "version r62678 of the ConfirmEdit extension for MediaWiki 1.16.x" kreeg ik een pagina met nog wat extra informatie:
A snapshot of version r62678 of the ConfirmEdit extension for MediaWiki 1.16.x has been created. [...]
Note that some extensions need a file called ExtensionFunctions.php, located at extensions/ExtensionFunctions.php, that is, in the parent directory of this particular extension's directory. The snapshot for these extensions contains this file as a tarbomb, extracted to ./ExtensionFunctions.php. Do not neglect to upload this file to your remote server.

bron: http://www.mediawiki.org/wiki/Special:ExtensionDistributor

Maar in die "snapsnot" zie ik geen "file as a tarbomb, extracted to ./ExtensionFunctions.php". Is dat bestand nu wel of niet nodig?

Ik ben een kleine 2 uur bezig hiermee. Om maar te bewijzen hoezeer ik me wil inzetten voor een McDrake bibliotheek van en voor bezoekers.
Moet ik even op gang gebracht worden, of verslikt ook een programmeur zich in deze materie?
Zoals MediaWiki op mij overkomt is het software voor fanatieke programmeurs met veel vrije tijd.


Toekomst van McDrake Wiki:
Caspar, weet jij raad met bovenstaande problemen? Kun jij de boel werkend krijgen? Ik begrijp dat ook jij teleurgesteld bent in de gebruikersvriendelijkheid van MediaWiki. Maar ik heb nogal wat hoop gevestigd op zo'n systeem. Sinds McDuck zit ik te hameren op een bibliotheek waaraan meerdere mensen kunnen werken zonder tussenkomst van het beheer.
Als jouw afwijzing betekent dat zo'n bibliotheek niet komt, ben ik verdoemd tot het beheren van alleen maar een kletsforum, dat nergens heengaat. Dit is nooit mijn doel geweest, integendeel. Ik wil iets constructiefs neerzetten. Die hoop zie ik nu verdwijnen.

Dus wat nu? Zonder "bibliotheek" heb ik eigenlijk niets meer te doen met McDrake, behalve mezelf oeverloos vervelen op de forumboards. Ook had ik met iets als MediaWiki gehoopt op een oplossing voor mijn sites, zoals 'A Guidebook to the Carl Barks Universe'.
Zonder voortgang van dat soort projecten ben ik als beheerder uitgespeeld op internet. Dan is het voor mij uitloggen en wegwezen. Ik ben uitgekeken op het in eenzaamheid werken aan een site.
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Appie Aap » di aug 10, 2010 4:08 pm

Daniel73 schreef:Vorige week is op 3 augustus 2010 een update uitgevoerd via Installatron. Die update is uitgevoerd door de provider, omdat ik een foutmelding kreeg. Er bleek een bug te zijn.
Zijn door deze update misschien instellingen gewijzigd? Ik kan pagina's bewerken ZONDER in te loggen!!

Volgens mij zijn er geen instellingen veranderd. Pagina's die als beschermd gemarkeerd staan, kan ik niet bewerken als ik niet ingelogd ben (probeer maar eens bij bijv. William Van Horn)
Avatar gebruiker
Appie Aap
Liefhebber
Member
 
Berichten: 1069
Geregistreerd: zo nov 22, 2009 1:15 am
Woonplaats: Duckstad

Berichtdoor Daniel73 » di aug 10, 2010 4:51 pm

Appie Aap schreef:Volgens mij zijn er geen instellingen veranderd. Pagina's die als beschermd gemarkeerd staan, kan ik niet bewerken als ik niet ingelogd ben (probeer maar eens bij bijv. William Van Horn)

Dat betekent dus dat er vele onbschermde pagina's zijn, diue elk moment kunnen worden aangepast?
Ik dacht dat gastbijdrages waren uitgezet. Als deze aan staan, kan de wiki elk moment platgespamd worden.

Overigens wijt ik deze problemen ook aan Installatron. Wat heb ik aan zo'n installeer-programma als ik er een alleen een kale, praktisch onwerkbare MediaWiki mee kan installeren?
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Caspar » di aug 10, 2010 8:04 pm

Ik twijfel er niet aan dat ik bovenstaande en meer problemen van de wiki wel kan verhelpen en allerlei functies toevoegen, maar ik vraag me af of het wel alle tijd waard is. Ik ben inderdaad zwaar teleurgesteld in MediaWiki en stel dan ook voor iets anders te proberen. Misschien zijn we te enthousiast geweest, door zo 'kaal' te beginnen en pas naderhand te kijken of er problemen waren en hoe we die moesten gaan oplossen.

En ik zou toch nog een keertje willen wijzen op Wordpress. Niet alleen is het een erg goede, solide en intuitief-werkende software, ook heb ik er al een aantal jaar ervaring mee en ben ik nooit teleurgesteld. De uitgebreide userbase zorgt voor vele plugins en themes. Ja, Wordpress is eigenlijk blog-software, maar er valt ook een mooie biblioheek mee te maken. Geregistreerde leden kunnen berichten posten, die, net als op de wiki, in categorieen kunnen worden opgedeeld. In plaats van de talk-pagina's zijn er comments, die trouwens ook uitgezet kunnen worden. Voor het plaatsen en aanpassen van berichten zijn verschillende instellingen. Ik zou er bijvoorbeeld voor kunnen zorgen dat iedereen berichten mag plaatsen, maar alleen bepaalde leden (bijvoorbeeld iedereen met meer dan x aantal gecontroleerde posts) mogen ook berichten van anderen aanpassen. Per bericht kan je ook weer permissies instellen. Dan krijg je dus grofweg drie rangen: schrijvers (schrijven alleen berichten), editors (schrijven en anderen aanpassen) en redacteurs (controleren berichten en aanpassingen). Voor de redacteurs/controleurs kan je ook weer kiezen of zij berichten op voorhand moeten controleren, of achteraf. En al deze opties zijn door mij makkelijk te maken! Ben jij geinteresseerd, Daniel? Is dit een uitkomst?
Caspar
McDrake's Willie Wortel
Member
 
Berichten: 799
Geregistreerd: ma jan 01, 2007 6:38 pm

Berichtdoor Daniel73 » di aug 10, 2010 8:11 pm

Inmiddels heb ik de ConfirmEdit aan het werk gezien. De standaard-configuratie weigert het toevoegen van externe URLs, heb ik ontdekt.
Ik probeerde de URL "http://www.google.nl" toe te voegen aan een willekeurige pagina. Dit triggerde ConfirmEdit. Ik moest eerst een rekensom oplossen.

Standaard-situatie in ConfirmEdit.php:
/**
* Actions which can trigger a captcha
*
* If the 'edit' trigger is on, *every* edit will trigger the captcha.
* This may be useful for protecting against vandalbot attacks.
*
* If using the default 'addurl' trigger, the captcha will trigger on
* edits that include URLs that aren't in the current version of the page.
* This should catch automated linkspammers without annoying people when
* they make more typical edits.
*
* The captcha code should not use $wgCaptchaTriggers, but CaptchaTriggers()
* which also takes into account per namespace triggering.
*/
$wgCaptchaTriggers = array();
$wgCaptchaTriggers['edit'] = false; // Would check on every edit
$wgCaptchaTriggers['create'] = false; // Check on page creation.
$wgCaptchaTriggers['addurl'] = true; // Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true; // Special:Userlogin&type=signup
$wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure

Nieuwe situatie:
$wgCaptchaTriggers = array();
$wgCaptchaTriggers['edit'] = true; // Would check on every edit
$wgCaptchaTriggers['create'] = true; // Check on page creation.
$wgCaptchaTriggers['addurl'] = true; // Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true; // Special:Userlogin&type=signup
$wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure

Ik heb de 'edit' en 'create' op "true" gezet.

Als ik nu probeer te editen, zonder in te loggen, moet ik eerst een rekensom oplossen. Bijvoorbeeld:
86 - 8 =

Kortom, na een stevige doch opluchtende huilbui begin ik de configuratie voorzichtig te snappen.
En als ik het snap, moeten er veel meer mensen het kunnen snappen. ;)

Bovenstaande configuratie betekent dat ook geregistreerde gebruikers verplicht zijn om rekensommetjes op te lossen. Maar ook hier heb ik inmiddels een aanpassing weten te maken.

Standaard-situatie in ConfirmEdit.php:
$wgGroupPermissions['*' ]['skipcaptcha'] = false;
$wgGroupPermissions['user' ]['skipcaptcha'] = false;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false;
$wgGroupPermissions['bot' ]['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop' ]['skipcaptcha'] = true;
$wgAvailableRights[] = 'skipcaptcha';

Nieuwe situatie:
$wgGroupPermissions['*' ]['skipcaptcha'] = false;
$wgGroupPermissions['user' ]['skipcaptcha'] = true;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false;
$wgGroupPermissions['bot' ]['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop' ]['skipcaptcha'] = true;
$wgAvailableRights[] = 'skipcaptcha';

Ik kan nu als gebruiker Daniel73 editen zonder dat ik een rekensom krijg.


Een probleem. Als ik probeer in te loggen met een fout wachtwoord, krijg ik géén rekensom. Maar in ConfirmEdit.php staat:
$wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure

Verderop in de configuratie staat:
/**
* Number of seconds after a bad login that a captcha will be shown to
* that client on the login form to slow down password-guessing bots.
*
* Has no effect if 'badlogin' is disabled in $wgCaptchaTriggers or
* if there is not a caching engine enabled.
*
* Default is five minutes.
*/
global $wgCaptchaBadLoginExpiration;
$wgCaptchaBadLoginExpiration = 5 * 60;

Ook met de (huidige) waarde 1 * 60 (1 minuut) krijg ik geen rekensom:
$wgCaptchaBadLoginExpiration = 1 * 60;

De 'badlogin' staat aan in $wgCaptchaTriggers, dus is blijkbaar "not a caching engine enabled". Hoe zet ik zo'n "caching engine" aan, als het probleem daaraan ligt?
Zonder deze functie hebben spambots nu de mogelijkheid om wachtwoorden te raden en accounts over te nemen - inclusief die van beheerders!

Mediawiki.org heeft een of meer pagina's over caching:
http://www.mediawiki.org/wiki/Manual:Configuration_settings#Cache
http://www.mediawiki.org/wiki/Manual:Cache
Heeft iemand enig idee wat ik zou moeten doen, als het probleem aan een cache ligt?


In elk geval is de McDrake Wiki een stapje verder. Hulp is welkom om die badlogin te activeren.
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Appie Aap » di aug 10, 2010 9:20 pm

Kijk aan! Hartstikke goed gedaan, Daniël! :D Geef de moed dus niet op!

Over dat probleem met Caching, zie deze pagina:

http://www.mediawiki.org/wiki/Manual:Configuration_settings

Er staat:

This is an index of all supported configuration options based on the DefaultSettings.php file.

Never edit DefaultSettings.php; copy appropriate lines to LocalSettings.php instead and amend them as appropriate.

Er staat verderop een link:

- $wgInterwikiCache -- Whether to enable the interwiki cache

Dit verwijst naar deze pagina:

http://www.mediawiki.org/wiki/Manual:$wgInterwikiCache

Interessant is dat er bovenaan staat "Default value: false". Wanneer je er dus nog niets mee gedaan hebt, staat Caching uit. Wanneer die aangezet wordt (waarde op 'true' zetten), zou die badlogin kunnen gaan werken.

Misschien heb je hier wat aan. :)
Avatar gebruiker
Appie Aap
Liefhebber
Member
 
Berichten: 1069
Geregistreerd: zo nov 22, 2009 1:15 am
Woonplaats: Duckstad

Berichtdoor Daniel73 » wo aug 11, 2010 1:25 pm

Appie Aap schreef:Kijk aan! Hartstikke goed gedaan, Daniël! :D Geef de moed dus niet op!

Dank voor je aanmoediging! Soms heb ik mensen nodig die mij herinneren hoe onovertroffen geniaal ik ben. :P


Ik denk dat "Interwiki" iets anders is. Geen idee wat. Het lijkt te gaan om een cache voor "Interwiki", terwijl ik een cache voor "ConfirmEdit" nodig heb. Maar dit gok ik.

Volgens mij ligt het probleem aan deze configuratie, in LocalSettings.php:
## Shared memory settings
$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = array();

Ik heb de waarde veranderd in "CACHE_ANYTHING".
Zie: Manual:$wgMainCacheType
Eerder heb ik in samenspraak met de provider, de permissie van de cache in de wiki-directory gewijzigd. Maar misschien was dat niet nodig geweest.
N.B. Is het openbaar vermelden van dit soort informatie verstandig? Kan het kwaad?

Zojuist heb ik opnieuw geprobeerd om met herhaaldelijk met een fout wachtwoord in te loggen en ik kreeg al spoedig een rekensom:
To help protect against automated password cracking, please solve the simple sum below and enter the answer in the box (more info):
49 + 9 =

Dit gebeurde ruim binnen een minuut. Bij mijn derde poging.

Ik neem aan dat de spambeveiliging nu geheel werkt.
(Maar hoeveel is 49 + 9?)
Daniel73
Member
 
Berichten: 922
Geregistreerd: zo dec 31, 2006 12:26 am
Woonplaats: Nederland

Berichtdoor Appie Aap » wo aug 11, 2010 1:38 pm

Dom van me. Ik heb twee sites door elkaar gehaald. :P Maakt niet uit, want gelukkig werkt de beveiliging nu! :D
Ik krijg nu aldoor na twee pogingen een captcha. En als ik het daarna te vaak doe krijg ik deze melding: "You have made too many recent login attempts. Please wait before trying again." En dan kan ik helemaal niet meer inloggen (voor een tijdje).
Avatar gebruiker
Appie Aap
Liefhebber
Member
 
Berichten: 1069
Geregistreerd: zo nov 22, 2009 1:15 am
Woonplaats: Duckstad

VorigeVolgende

Keer terug naar Over McDrake Nederland Disney

Wie is er online

Gebruikers op dit forum: Geen geregistreerde gebruikers. en 6 gasten

cron