[GRASS-user] Cannot get past Wiki captcha

Hi,

2011/11/22 Hamish <hamish_b@yahoo.com>:

why aren't we using the standard and very well tested debian
package for mediawiki?

that's simple, because than we would use for years (assuming that you
are not reinstalling OS when new stable Debian release will appear)
quite old version of mediwiki, in this case 1.12. Note that the
current version is 1.17. What's the problem with using recent *stable*
release of Mediawiki, which is BTW quite well tested to, at least for
Wikipedia? I am running several mediawikis from SVN (always recent
stable release) on Debian and I have no problem with that for last two
years. BTW, when updating your instance to the more recent version,
it's just matter of running `svn up` :wink:

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

It's also possible to change the captcha plug-in.
Maybe a different one will work better:

  http://www.mediawiki.org/wiki/Extension:ConfirmEdit

Also, there are some hints on that page about
problems with the captcha and WikiMedia dependencies.

Best,

Ben

--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke@fastmail.fm

On Tuesday, November 22, 2011 3:10 PM, "Martin Landa"
<landa.martin@gmail.com> wrote:

Hi,

2011/11/22 Hamish <hamish_b@yahoo.com>:
> why aren't we using the standard and very well tested debian
> package for mediawiki?

that's simple, because than we would use for years (assuming that you
are not reinstalling OS when new stable Debian release will appear)
quite old version of mediwiki, in this case 1.12. Note that the
current version is 1.17. What's the problem with using recent *stable*
release of Mediawiki, which is BTW quite well tested to, at least for
Wikipedia? I am running several mediawikis from SVN (always recent
stable release) on Debian and I have no problem with that for last two
years. BTW, when updating your instance to the more recent version,
it's just matter of running `svn up` :wink:

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

2011/11/22 Benjamin Ducke <benducke@fastmail.fm>:

It's also possible to change the captcha plug-in.
Maybe a different one will work better:

http://www.mediawiki.org/wiki/Extension:ConfirmEdit

we already use this extension...

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Yes, but I was thinking about switching the
captcha type (the extension seems to support
several different ones). Who knows, maybe the
current captcha type conflicts with the system
setup.

Ben

--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
  
  benducke@fastmail.fm

On Tuesday, November 22, 2011 3:25 PM, "Martin Landa"
<landa.martin@gmail.com> wrote:

2011/11/22 Benjamin Ducke <benducke@fastmail.fm>:
> It's also possible to change the captcha plug-in.
> Maybe a different one will work better:
>
> http://www.mediawiki.org/wiki/Extension:ConfirmEdit

we already use this extension...

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

2011/11/22 Benjamin Ducke <benducke@fastmail.fm>:

Yes, but I was thinking about switching the
captcha type (the extension seems to support
several different ones). Who knows, maybe the
current captcha type conflicts with the system
setup.

I will do same tests later.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

On Tue, Nov 22, 2011 at 2:57 PM, Hamish <hamish_b@yahoo.com> wrote:

Martin:

long time and most of cleanup has been done MarkusN and me.

no doubt.

fwiw, if you check the block logs I think you will find that you
are not alone in that.. (a while ago I did some 100+)

I guess we don't have to argue about that but Martin and me
were really swamped with this cleanup (which I also do for
the OSGeo wiki) that it was no longer acceptable.

Re LDAP: since the Wiki logins were separate from the OSGeo
LDAP, many users will have differing names. This makes a Wiki
migration to LDAP authentication a difficult (read: manual) job.
See the OSGeo-SAC list for the discussion.

why aren't we using the standard and very well tested debian
package for mediawiki?

Since the Debian version on the shared projects-machine from
OSGeo is the last but one version, its Mediawiki version is just
antique... It lacks several features we are using for years.

Markus

2011/11/22 Martin Landa <landa.martin@gmail.com>:

2011/11/22 Benjamin Ducke <benducke@fastmail.fm>:

Yes, but I was thinking about switching the
captcha type (the extension seems to support
several different ones). Who knows, maybe the
current captcha type conflicts with the system
setup.

I will do same tests later.

also confirmed that captcha avoids creating new accounts. I will
investigate more ASAP.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Hi,

2011/11/22 Martin Landa <landa.martin@gmail.com>:

also confirmed that captcha avoids creating new accounts. I will
investigate more ASAP.

I changed type of captcha from FancyCaptcha to SimpleCaptcha which
seems to work. I have also enabled captcha for 'addurl' (also for
sysops). In the next days I would like to switch to MathCaptcha. What
do you think about that?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Martin wrote:

I changed type of captcha from FancyCaptcha to
SimpleCaptcha which seems to work. I have also
enabled captcha for 'addurl' (also for sysops).

excellent! glad we have something in place again.

could you determine if the FancyCaptcha extension
was to blame for the problem? if so, was there a
bug report?

Hmm, didn't we used to use reCaptcha? (or is that a
config option as part of FancyCaptcha?)
if not, it would be my preferred option as it is
not so much wasting humanity's time. (even if it
is now free labor for google instead of helping out
Project Gutenberg as it once was, it is still better
than throwing your finite energy down a hole, which
I find to be highly demotivating)

In the next days I would like to switch to
MathCaptcha. What do you think about that?

how about this one:
http://www.dennis2society.de/main/dennis2society-advanced-math-captcha

only half-kidding :wink:

cheers,
Hamish

ps- very glad to see the <math> TeX extension
working again!! thanks

pps- fwiw, no 1.17 yet, but official more modern
versions of mediawiki are in fact available for
debian stable from backports.org, and the equiv.
<version>-backports repositories.
  http://packages.debian.org/mediawiki

"Stable packages" in the Debian sense is as much
about package integration and compatibility with
the rest of the OS as it is about the quality of
a particular software release. (and that can take
a very long time to gel, so you get old versions
that are guaranteed to work together instead of the
newest shiny) If what you've set up now is working
well I would not suggest to change it, only
mentioned as the problem at hand seems to be a
system integration issue, and that's exactly what
using the official packages is designed to prevent.
Also fwiw, -- & I fully accept that mediawiki is
probably the most widely tested web code out there--
but wrt 'svn up': running development code on a
production server is generally considered to be
not the best strategy.

Hi,

2011/11/27 Hamish <hamish_b@yahoo.com>:

Hmm, didn't we used to use reCaptcha? (or is that a
config option as part of FancyCaptcha?)
if not, it would be my preferred option as it is
not so much wasting humanity's time. (even if it
is now free labor for google instead of helping out
Project Gutenberg as it once was, it is still better
than throwing your finite energy down a hole, which
I find to be highly demotivating)

agreed, on the other hand (cited [1])

Unfortunately, reCAPTCHA might be a victim of its own success - as of
2011, some spammers appear to have figured out a way to bypass it,
either through character recognition or by using humans. For that
reason, it is not necessarily recommended.
Part of the weakness of the ReCaptcha module is that ConfirmEdit
doesn't include any penalty mechanism, so spam bots can simply keep
trying to bypass the CAPTCHA until they get through. This is an issue
that is strongly worth addressing in some way.

Martin

[1] http://www.mediawiki.org/wiki/Confirmedit

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Unfortunately, reCAPTCHA might be a victim of its own success - as of
2011, some spammers appear to have figured out a way to bypass it,
either through character recognition or by using humans. For that
reason, it is not necessarily recommended.

I can confirm this. On another site that I manage, based on
phpBB, I get unbelievable amounts of spambot requests to
open accounts. Apparently, simple graphical captchas no
longer hold them back. I think math captchas are a good idea.
Plus, it's free brain exercise :slight_smile:

Cheers,

Ben

Part of the weakness of the ReCaptcha module is that ConfirmEdit
doesn't include any penalty mechanism, so spam bots can simply keep
trying to bypass the CAPTCHA until they get through. This is an issue
that is strongly worth addressing in some way.

Martin

[1] http://www.mediawiki.org/wiki/Confirmedit

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Martin:

> Unfortunately, reCAPTCHA might be a victim of its own success - as
> of 2011, some spammers appear to have figured out a way to bypass it,
> either through character recognition or by using humans. For that
> reason, it is not necessarily recommended.

If they have humans working for them no turing test will suffice.
(or, perhaps the advanced math one..)

this is why I think it is good to keep the captcha for urls. They could
have humans create the accounts and then spambots polute 100 pages once
the account is created. i.e. make it as expensive for them as we can.

Ben:

I can confirm this. On another site that I manage, based on
phpBB, I get unbelievable amounts of spambot requests to
open accounts. Apparently, simple graphical captchas no
longer hold them back. I think math captchas are a good idea.
Plus, it's free brain exercise :slight_smile:

> Part of the weakness of the ReCaptcha module is that ConfirmEdit
> doesn't include any penalty mechanism, so spam bots can simply keep
> trying to bypass the CAPTCHA until they get through. This is an issue
> that is strongly worth addressing in some way.

I guess reCaptcha doesn't mind the spammers working for them, free labor!
:slight_smile: ok, that's probably being way too cynical, this is ConfirmEdit's bug
not reCaptcha's.

> [1] http://www.mediawiki.org/wiki/Confirmedit

hmmm, can't hurt to put a "sleep(3)" on a fail, line 119?
  http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/ReCaptcha.php?revision=104064&view=markup

and increment a counter, which if you fail ~10 times then replace the
call to $editPage->showEditForm( array( &$this, 'editCallback' ) );
with a message saying that "we could not verify that you were human and
your edit was unable to be submitted: make a copy of your work and try
again later"?

or perhaps mix it up a bit: if the reCaptcha fails 3 times switch to
the math captcha, if that fails 3 times failover to simpleCaptcha,
if that fails three times have mediawiki ban the IP address for 24 hours.
sort of a cascading fail2ban.

shrug,
Hamish

Hi all,

FYI:
I have modified the captcha in the Wiki today and
added a modification to mix image and ASCII for
the simple math exercise to solve when
- registering a new user
- adding a new page
- adding an external link

This should help to keep even the improved spambots
out (at least for a while).

In case of troubles please notify me. I am running this
already on the OSGeo Wiki for some days, looks
pretty good.

Best
Markus