I have noticed how some type of spambots randomly edit wiki pages replacing possibly good content with..spam. Sometimes these pages are in the houndreds. It's very time consuming to go and restore all of them. So, I suggest a undo banned IP's changes. For example, if I ban Mister X I want to be able to press a few buttons and get rid of all his changes. That, or a page where I can select multiple pages (such as some check boxes on the RecentChanges page) and then an action button / drop down. Actions would include "revert to previous version", et cetera. --[BryanBishop]
Some of the administrative features, like "editlinks", affect the entire Wiki. Others, like the ones that delete, lock, and unlock a page, require that a page ID be included in the link. To use them, then, you either need to add that link to every page, or remember what it looks like and type into to your browser by hand.
What if an "Admin" link was added to the goto bar, only if the user has the admin password? This would lead to a generated page that has the appropriate admin action links for the page on which they clicked. --WillDuquette
Yes, it is great, I want it :-). In fact, you can add also site wide admin function. So, if new commands are created in a next release, you will see these without reading the documentation. --ThierryExcoffier?
We have found that we use our UseMod wiki mostly to discuss and document software development issues. We end up with lots of references to software modules, classes, etc. Many of these have names that look like WikiWords, and thus get spurious question marks after them. Because of this, we're considering turning off the traditional WikiWord links and requiring people to use explicit FreeLinks instead.
The hard part, of course, is making the transition. If I just turn of the wiki link feature, I'll break a lot of links. Does anyone else have experience making this change? If I could figure out how to correctly update the pages in the database, I could probably write a Perl script to change existing, valid WikiWord links to free links. Or is there some way to use the "rename page" admin feature to achieve this?
-- DanMuller
I think that OddMuse has such a feature. You can enclose such words with the "nowiki"-tag and they won't be processed from the script. I don't know whether UseMod has such a feature.
=SomePageName=Some Page Name =AnotherPageName=Another Page Name
I'd really like to see an alteration to the way IP Banning is handled. Whereas you have a setup for generally allowing and banning specific IPs, you don't seem to have a setup for the other way around - only let IPs from this list work on the Wiki.
^61. ^220. !^61.1.2.3
I'm in an odd constrained situation where IP tunneling can't be used (old servers), where .htaccess isn't a good solution (the corporation says I'm not high-level enough to touch that and nobody wants to make changes to help set up a Wiki), and where I'd still like to use a Wiki with a few people from a few disparate locations.
As a seperate issue, I realize that you don't want to implement access control (not editing/deleting control, but <b>access</i> control) per-page or defacto. The truth is, for a lot of us, this is the only Wiki that's just drop-and-go, and it'd really help to be able to use a Wiki setup in at least a semi-secure fashion. (my case is for getting documentation formed for a project that I don't want everyone and their mother on the 'net to know about; the project is too big to sort all at once, and the Wiki structure helps)
That said, there are a lot of people asking for it, in one form or another. Would you consider adding it, and just turning it off by default?
^128.40-50. might block everything in 128.40.*, 128.41.*, 128.42.* ... 128.50.*
I'd put in a vote for this. Look at SpammingAddresses - it's getting to be a real pain entering all the values, even if you block based only on the 1st address byte (which may penalize legit users). Plus you really want it arithmetic, rather than based on characters. Maybe some kind soul will write this enhancement, and make it available for the rest of us! --PaulMorrison
It's simply not necessary. Any contiguous range of IP addresses can be matched with a regular expression. It's not always pretty, but it's pretty easy once you've done it a few times.. For example, 128.40-50 above can be matched as ^128\.(4\d|50)\. Most of the time it's easier (and sufficient) to block an entire /24 or in the case of Korea and China, the /16 (and Meatball now blocks ChinaNet?'s /8). Dynamic IP ranges tend to be allocated in those sizes anyway, so blocking a smaller range isn't very productive. --ChuckAdams
I take your point,Chuck, but decided to get it working anyway - on a copy of my own wiki, but haven't rolled it out yet. I may do that if I find I am spending a lot of time adding addresses! The convention is e.g. <128.63-129.27>, so I don't have to keep adding those backslashes, and IMHO it's more legible than the regexps. The start address is padded with 0's, while the end address is padded with 255's. If anyone is interested, I'll post the code somewhere... --PaulMorrison
For example: ^192\.168\.
That regex will match any ip starting with 192.168. You don't need \d+ which means "one or more of any whole number" because this will already match any numbers following 192.168 by implication, by leaving them out. You don't need $ because this regex doesn't care what's at the end of the string.--JAPH
I recently had a client with lots of spam. This client also has a weblog (MT) and we'd installed the Blacklist plugin to fix that... I thought, why not just apply the Blacklist to new Posting similarly to the way it's done in MT... so I added this: sub ContentIsBlacklisted? {
![[Home]](/wiki.gif)
my ($newText) = @_[0];
my ($status, $data);
($status, $data) = &ReadFile("$DataDir/blacklist");
return 0 if (!$status); # No file exists, so no ban
foreach (split(/\n/, $data)) {
next if ((/^\s*$/) || (/^#/)); # Skip empty, spaces, or comments
return 1 if ($newText =~ ("(?i)" . $_));
}
return 0;
}
which the astute reader will notice looks a lot like UserIsBanned?. I also added:
if (&ContentIsBlacklisted?($string)) { &ReportError(T('Blacklisted content found.')); return; }
in DoPost? after the UserCanEdit thing. I then dumped the whole Master Blacklist in... it didn't work right... I should be trimming whitespace and stuff... there's also a problem with the expressions used, and since I don't know regexp so well, I decided to leave it. However, all the link junk in the last 95% of Blacklist works and (zyrtec|cialis|proscar|mevacor|norvasc|clomid|glucophage|ativan|cipro|amoxil|celebrex|claritin|wellbutrin|soma|zovirax|zanaflex|vasotec|zantac|zocor) is a valid entry that works.
It runs through content pretty fast and posts a little message (which I'm thinking about adding the blacklisted match to). It'd be great if someone could make it work on stuff like: (valtrex|zyrtec|\bhgh\b|ambien\b|flonase|allegra|didrex|renova\b|bontril|nexium)[\w\-_.]*\.[a-z]{2,}
and(blow)[\w\-_.]*job[\w\-_.]*\.[a-z]{2,} (buy)[\w\-_.]*online[\w\-_.]*\.[a-z]{2,}
I might tackle that problem later if it becomes really annoying. I hope this is useful to people, and I hope someone wiser than me can make it work even better.
My changes were made on 0.92 and I'm eventually gonna look at how it fits in with 1.0, but I assume it'll be same old.
Stuart Thiel (sthiel@cs.concordia.ca)
I seem to have had some success blocking spam - in several months only one spammer, and s/he is now (the only one) on my banned list! I put some instructions on how to build a string and insert it as the Edit password, on the home page (to make it a captcha, I didn't specify the string, but gave instructions on how to build it). I ran like this for several months with no spam at all, but very few bona fide visitors either. I therefore created a page called Captcha with the same instructions, and extended the "This page is read-only" message in my copy of the Usemod code with a reference to the Captcha page. Got several bona fide visits, and one persistent spammer (from Russia, I believe). Adding him/her to the banned list didn't stop him/her - I then realized that in Usemod, edit authority takes precedence over banned. I have now changed my copy of the code so the banned list takes precedence over edit authority, but not over admin authority. There hasn't been a single case of vandalism since - knock on wood! To give it a try, see http://www.jpaulmorrison.com/cgi-bin/wiki.pl. Feedback? --PaulMorrison
I lied - it turns out that several people managed to insert messages into the "user" pages, I assume as fake user names - some quite long (e.g. lists of medications). The interesting thing is that, of course, these changes do not show up in RecentChanges (or All Changes). I have now changed the permissions on all files to read and write for owner only, and made the wiki by invitation only... Pity! --PaulMorrison
Sometimes those edits are marked as minor edits and don't show up on RecentChanges unless you set it otherwise in your prefs or add showedit=1 to the URL with action=rc. I'm still evaluating some antispam measures. Here on usemod most of the bad edits seems to be from on botnet which usually only add one word at the beginning of a page. Links were seldom used, but maybe would be easier to cope with. -- MarkusLude
Sorry, I meant that they were able to put the "spam" into the UserName? in Preferences. I did a test using my own wiki and I was able to do this without having even edit authority. How about blocking users from doing this unless they have at least edit authority - after all, why set a username unless you can update pages? PS I have added a check to DoUpdatePrefs? and it seems to work - I can publish it if people are interested. --PaulMorrison
Editing the prefs is needed to set the edit password. If the user name is somewhat strange, maybe we could add some restriction to it like the format of the user name must conform to the link pattern (or free link pattern, if active). But on the other hand, what do they gain from this as long as they can't edit any pages and thus the user name doesn't appear anywhere? I don't see the problem at the moment. -- MarkusLude
I would assume the added stuff would show up in a Google search, but of course not on the wiki. One person had put in a plug for Yevtushenko for presudent (sic), and other web sites mentioned ended in .cz (Czechoslovakia I assume). As you say, not a big problem, but annoying even so!
I do have one suggestion: someone should look at the files in the "user" directory of UseMod and check visually for vandalism, using a tool like FTP95PRO. They won't show up any other way. Since my wiki uses essentially the same software as UseMod, the same people have very likely vandalized UseMod as well. --PaulMorrison
Here we don't have any really strange "user names" in the user files. Only a few spam entries as the stylesheet. Thats all. Why do you think some of this may show up in a google search? Noone should be able to access the user files through the web. Preferable the DataDir is outside of the document root of the webserver anyway. -- MarkusLude
I couldn't figure out which fields they had modified, as I'm not familiar with the structure of the user pages, so it was probably the stylesheet in my case too. I assume they did it to improve the Google rankings of their web sites. Your point about access relates to a question I asked elsewhere but didn't get an answer to: what permissions should be used for the wiki directories? The webserver is using phpsuexec, so I think we can use rw- for owner, and no access for group and other, for all files, but new files were defaulting to rw-r--r--, so I added a umask(077). Is this necessary / a good idea? I didn't know about putting the DataDir outside of the document root of the webserver - I haven't seen that in any documentation, but maybe it's obvious to *nix-speakers! Thanks. --PaulMorrison
I'll take a look at the permission stuff during the next days. Normally I try only to put stuff in the document root of the webserver which is directly served by the server like static pages, images, php scripts. I put CGI scripts in some extra script directory outside as well as data used by scripts. My prefered layout looks like:
This prevents usually from direct access to the data stuff through the web. The webserver should need read rights for htdocs/ and cgi-bin/ and write rights only for data/. With some (most?) web hosting services this may be hard or impossible to configure. -- MarkusLude