UseModWiki | WikiSuggestions | RecentChanges | Preferences

Place suggestions about administrative features here.

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

I though so too when I started looking at using UseMod wiki, so I coded these features into my version. If you are interested have a look at http://www.razar.f2s.com/cgi-bin/newwiki.pl DeadLink [cache] and then go to preferences, set the admin password to 'relgor' and check the show admin bar box as well. I am happy for anyone to get a copy of this. --Razar

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?

The next release (1.0) includes an admin toolbar on the bottom of each page if you are an admin. --CliffordAdams

This is more question than suggestion...

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.

That feature was originally in UseModWiki (and was inherited by OddMuse). The "rename page" feature can be used to change the links (presuming the checkbox "Substitute text for rename" is checked), but you will need to enter each line like:
=SomePageName=Some Page Name
=AnotherPageName=Another Page Name
You could write a simple Perl script to take the index listing (action=index) and output the proper rename commands. (I would just split at all capital letters, then manually scan the list for changes.) Note that if your web server limits the runtime of CGI commands (like many shared-hosting companies do) then you may want to enter only a few rename commands at a time. (You could safely rerun any list that didn't finish, but it is possible that the script could be stopped in the middle of rewriting a page.) If you have any questions about this procedure, please feel free to email me. --CliffordAdams

That's a great idea, but I didn't really want to rename all of the pages -- just force the existing links to have double-brackets. But I'll entertain the idea of actually renaming the pages. (A total of 732 pages, btw.) -- DanMuller

ip banning alternatives

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.

An exclude check list would be nice when banning a complete range but wanting to allow select exceptions.
For example some Asian spammers:

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?

[I considered this and finally rejected it for 1.0. The following text is kept for context.] I'm now considering a setting (default-off) which would allow only people with editor passwords to view pages. (Users without editor passwords could only go to the Preferences page where they could enter a password.) I will probably add a function to check whether viewing is OK--you could change that pretty easily to add an IP check. This feature might make it into 1.0. --CliffordAdams

OddMuse has an option "banned can read" which defaults to 1. So then you can ban all users by using "." as the regular expression, and setting the "banned can read" option to 0. Now only people with one of the passwords can read the site. --AlexSchroeder

After further thought I decided not to implement any view-restricting features for UseModWiki 1.0. I do not have enough time to adequately test new security-related features before 1.0, and I feel it is better not to promise security that might not be delivered. Those who still want such a feature are encouraged to look at OddMuse or other wikis. --CliffordAdams

MichaelBuschbeck has written this for his JDN wiki -- ask him to produce a patch at Unreal:Mychaeel

Alternately, maybe IP banning by range:

^128.40-50. might block everything in 128.40.*, 128.41.*, 128.42.* ... 128.50.*

I'm not planning to do this in 1.0. --CliffordAdams

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:

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? {

    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.'));

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,}

(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

UseModWiki | WikiSuggestions | RecentChanges | Preferences
Edit text of this page | View other revisions | Search MetaWiki
Last edited October 31, 2019 7:56 pm by JuanmaMP (diff)