Difference between revisions of "User talk:ConRunnerAdmin"

From ConRunner
Jump to: navigation, search
(Recent spam modus operandi: new section)
m (Recent spam modus operandi: typo)
Line 46: Line 46:
 
== Recent spam modus operandi ==
 
== Recent spam modus operandi ==
  
Looks like it's a script that tries to create a user, and if that successds immediately tries to create a spam page with that user.  Whether or not the page creation succeeds, the user is never used again.  The script has some ability to defeat a CAPTCHA but not always.  Can we put some kind of manual intervention into the user creation process?  Even something that just made new users wait an hour would defeat this script.  --[[User:Phi|phi]] 10:37, 8 February 2011 (PST)
+
Looks like it's a script that tries to create a user, and if that succeeds immediately tries to create a spam page with that user.  Whether or not the page creation succeeds, the user is never used again.  The script has some ability to defeat a CAPTCHA but not always.  Can we put some kind of manual intervention into the user creation process?  Even something that just made new users wait an hour would defeat this script.  --[[User:Phi|phi]] 10:37, 8 February 2011 (PST)

Revision as of 11:38, 8 February 2011

Questions about how the site is being administered? Put them here.


Please look at the discussion here:

http://www.conrunner.net/wiki/index.php?title=Talk:ConChair

It comes down to the fact that I think it would be great to update conrunner to mediawiki 1.9 to take advantage of sortable tables. --Tbmorgan74 15:35, 14 February 2007 (PST)

Done last weekend. I see you;ve made use of it already! --ConRunnerAdmin 08:45, 22 February 2007 (PST)

I think it's time to restrict the privileges of newly created accounts. --phi 13:48, 12 June 2007 (PDT)

Yeah. I was looking at the newest version of MediaWiki, to see if it has Captcha or something like it. --ConRunnerAdmin 16:16, 12 June 2007 (PDT)
It's called ConfirmEdit. http://www.mediawiki.org/wiki/Extension:ConfirmEdit --phi 09:29, 2 July 2007 (PDT)
Even better, you can blacklist usernames of the form this particular spammer uses. http://www.mediawiki.org/wiki/Extension:Username_Blacklist --phi 09:35, 2 July 2007 (PDT)
I suppose it is time to deal with this. Running guard duty every day is getting annoying. I'll look at it when I get back. --Bill Taylor 17:29, 2 July 2007 (PDT)
After much laboring with Windows Linux FTP and PHP, I think I have FancyCaptcha running. That should slow them down a bit. --Bill Taylor 16:29, 19 August 2007 (PDT)
"A bit" seems to have been about three years. That's pretty good... but maybe user creation approval or simply blocking China IP addresses is the next step? phi 16:50, 27 August 2010 (UTC)
Yes the attacks seem to be breaching the defenses better lately. We need to fall back to a more defensible position. This is like an old movie.
Since we haven't had a lot of legitimate users joining lately, I could go to approval method. Its just that I don't always get to check email everyday, and they change access rules from work pretty much weekly, so I'll need to spread the duties around. You've done a great job of policing (thanks!), I just didn't want to burden people with a silly task like that. --Bill Taylor 00:04, 28 August 2010 (UTC)


conrunner.net as a conrunning resource

Bill, Lets suppose that a non profit con X had need of mediawiki enviroment. Instead of setting one up themselves, they could use a corner of conrunner.net to create some pages. They might use it for their program line up for example. Anyone with a conrunner account could contribute to their ideas, and that may not be a bad idea. But lets suppose they wanted to restrict read or read/write access. Can you grant admin type privileges to certain users so that they can then in turn grant permissions to their staff to execute their ideas. Or Would you personally have to directly set up each permission manually? --Tbmorgan74 10:09, 13 July 2007 (PDT)

Mediawiki only allows for three levels. Owner, admin and regular user. I can retain owner, but once I set admin privs, that person has the run of the whole board. They can turn anyone on and off. Users can read and write to anywhere too. There is very little that they can't do, except set other user privs and protect or delete pages. I don't know of a way to individually set read/write privs on individual pages for individual users. Either everyone has it or no one does.
I could see people setting up a category and running their own little show in their own little corner. I don't mind the activity or the disk space. But there is no way to strictly control access. Any visitor could see it if they knew where to look. Mediawiki can control that, but again it is an all or nothing thing.
On the other hand, Mediawiki is easy to set up in general. They have well developed packages and good instructions. The first few days suck, setting all the parameters to fine tune things, but if all you want is a bare bones site, you can have one in a few minutes to a few hours, depending on your ISP, then set up whatever limited privs are needed for the small group working the project. Dreamhost.com is quite good. Pair.com as well. And a ton of others. The longest delay is getting your new domain to propagate to local DNSs. --ConRunnerAdmin 10:56, 13 July 2007 (PDT)

uploading files

Time to turn that off for newly created users, I guess. I don't have permissions to delete the spam files, or I would. -- phi 12:05, 6 December 2010 (PST)

OK, uploads are temporarily disabled. I'll bring them back this evening, when I have a chance to go over the user list. --ConRunnerAdmin 09:22, 7 December 2010 (PST)

Recent spam modus operandi

Looks like it's a script that tries to create a user, and if that succeeds immediately tries to create a spam page with that user. Whether or not the page creation succeeds, the user is never used again. The script has some ability to defeat a CAPTCHA but not always. Can we put some kind of manual intervention into the user creation process? Even something that just made new users wait an hour would defeat this script. --phi 10:37, 8 February 2011 (PST)