Overleg gebruiker:Carlb

Uit Mechelen Mapt, het vrije naslagwerk over Mechelen
Versie door SomeHuman (overleg | bijdragen) op 29 sep 2012 om 21:12 (→‎Minor spam question: update)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Naar navigatie springenNaar zoeken springen

Welkom bij Mechelen Mapt, Carlb! U kunt ook meewerken aan deze encyclopedie over Mechelen: wees niet beschroomd een fout te verbeteren of een artikel aan te maken. Neem ook even een kijkje bij de hulponderwerpen, indien u iets niet duidelijk is. Als u nog met vragen mocht zitten kunt u ons steeds een e-mail sturen. Nogmaals hartelijk dank voor de interesse!

Just to make your talk page link blue ;) Cartoonist | Contact | 21 mrt 2010 18:01 (UTC)

Background image[bewerken]

Isn't it possible to get the whole bg image on place again? Now it seems it's cut in the middle somewhere (showing a pub, a bank, and the PizzaHut, lol) Cartoonist | Contact | 24 jul 2011 22:53 (UTC)

User registration process[bewerken]

Hi Carl,

The Mechelen Mapt site has been suffering a good deal of automated spam lately. None of its three regular editors finds the time to cope with anything else here. The typical behaviour is the creation of a new user, which then takes one of three lines of action:

  1. Simply wait.
  2. Create a bogus user and/or user talk page with one or more linked urls.
  3. Create a new article with a bogus title, and several urls within the content.

As long as the modus operandi remains as is, it suffices to block the registration of a new user: Last month, there were merely 2 improper edits by an IP user.

Mechelen Mapt is a small wiki, and its language is Dutch, one that is unfamiliar to the creators of this spam. Developers of spambots are unlikely to be eager to spend the time and effort to try and circumvent peculiar protection methods of a for their purpose unimportant wiki. That's why I thought of using the locally controllable common.js to cause them some problems. Of course, spambots will not have JavaScripting turned on, so they don't even notice anything and continue their devious activity on Mechelen Mapt. Normally, a wiki should be accessible without JavaScripting and by a non CSS capable browser. But for Mechelen Mapt, it is quite acceptable to require functionality of both just for registering a new user. (And for creating a new article, but as things are, that is not really needed, and would also be more complicated at the Php server side.)

Therefore, the Php should generate a user registration page with the submit button disabled (pure Html attribute disabled="disabled"). For clarity towards real users, the form should remain invisible, which is a CSS property. All modern browsers do support CSS, thus that will not pose a problem (and it is by no means vital to the protection). Thus JavasScript becomes necessarily enabled at the user side for my script to turn the submit button disabled = false (and form style="display:block;"). It only does this after successfully passing an original security check (understanding some Dutch is tested and key/mousedowns are monitored) that cannot be disregarded while JavaScript is on. Of course, a Html <div> notifies the user that CSS and JS are required to register, and offers an e-mail link in case this would be hard to do (E.g. by company policy and no other PC available). When JS is functional, one of my scripts sets CSS display:none on that <div class="HideByJS">. The described process has been tested under all circumstances, be it by human users only. It is ready and waiting for your intervention:

Fortunately, the Php sources that I could find (from another wiki), show that the entire registration interface is an included pure Html sequence, and I expect this to be the case for us as well.

The Php (includes/templates/Usercreate.php ???) straightforwardly writes this into the page (the three required additions are shown in green colour):

<div id="userlogin">
<div class="HideByJS">Om u op de meest anonieme wijze als gebruiker te registreren, vergt onze beveiliging dat uw browser JavaScript effectief verwerkt en als alle moderne browsers Cascading Style Sheets (CSS) ondersteunt. Nu blijkt in uw geval minstens een van beide niet in orde. Ziet u geen mogelijkheid om dit te verhelpen (instelling van de browser en/of firewall, of vanaf een andere PC), dan kan u zich kort voorstellen (uw echte naam mag maar hoeft niet, wel de gewenste gebruikersnaam; voorbeeld waaraan u wil bijdragen...) in een <a href="mailto:[email protected]" class="external text" rel="nofollow">e-mailtje</a>. U krijgt zo spoedig mogelijk (normaal zeker binnen 48 uur) een antwoord waarmee u zich toch kan registreren en wij maken uw gebruikers- en overleg-gebruikerspagina's aan.</div>
<form ... id="userlogin2" ... style="display:none;">
<input type="submit" ... id="wpCreateaccount" ... value="Registreren" disabled="disabled"/>

Please do copy the literal Html text from this normally displayed talk page, not from its edit source.
In either the same or some other Php, there should also be:

<input type="submit" ... id="wpCreateaccountMail" ... value="Registreren per e-mail" disabled="disabled"/>

but in case this can not be found immediately, it probably does not matter (registering by e-mail is not a problem and that button does not even appear in the more normal situations).

This has all been explained in Dutch on Henning's talk page, who gave his consent. I expect him to send you an email soon, in which he will also ask to upgrade the wiki to version 1.20 alpha. But please, do the above very simple modification on the old version first, so that for at least a couple of days we can verify whether my method actually helps against the spam plague. On an at the same time upgraded version, we could never be sure that any improvement would be caused by my thingy or by some other software difference that 'our' current spambots simply don't aim for.

Sincerely Yours,
SomeHuman 2012-09-26 01:55-05:19 (UTC=CEST-2)

Minor spam question[bewerken]

Rarely upon attempting to block an IP by clicking 'blokkeren' (=' block') behind the user ID's reported IP, instead of the blocking form a message like "ProjectHoneyPot ( - Suspicious & Comment Spammer) DroneBL counter.sample.txt is missing, I need this to create counter.txt unless you are going to create it yourself?" appears in the otherwise empty browser window. (For other readers: the aforementioned IP is not the one that needed blocking, which was
Remarkable: a spambot 'user' had been working from 2 IPs, and, which generate "ProjectHoneyPot ( - Suspicious & Comment Spammer) DroneBL" etc and "ProjectHoneyPot ( - Suspicious & Comment Spammer) DroneBL" etc respectively.
Another user's IP showed "ProjectHoneyPot ( - Suspicious & Comment Spammer) DroneBL" etc., and a double IP user had only one,, showing "ProjectHoneyPot ( - Suspicious & Comment Spammer) DroneBL" etc.
The etc type of message also appeared three times for "Spamhaus (SBL)", most recently while failing to block and

Without any preceding name of the listing entity, the message has "DroneBL counter.sample.txt is missing, I need this to create counter.txt unless you are going to create it yourself?" for, for, and for And once more, both known IPs and of a same user produce that identical message.

I know it's some kind of blacklist verification process in Php (Extension:Check Spambots/functions.php ???), though I wouldn't dare to guess how "to create it myself", that counter.txt. The error occurs seldomly enough (approx. 1%) to have me wondering what precisely may cause those few IPs to be so different from all others with identical histories on the wiki.

This type of error obviously prevents putting our own block on those IPs. Would it also prevent the assumed Php blacklist checking, leaving a warranted open access for those proven bad IPs (apart from Php blacklists checks in tandem and from our own range blocks)?
SomeHuman 2012-09-28 22:45 - 2012-09-29 23:12 (UTC=CEST-2)