[Home]AdminFeatures

UseModWiki | RecentChanges | Preferences
UseModWiki 0.90 and later include some "admin" features. A new configuration variable $AdminPass has been added. By default it is "", which disables all admin features. It can be set to a space-separated list of passwords, allowing multiple separate passwords to be given out.

Users are considered "admins" if UserIsAdmin (their "administrator" password (set in Preferences) is the same as any admin password). Alternatively, one can add "adminpw=password" to the command line (see below), but it puts the password into the site's logs. (On usemod.com and many other sites the logs are semi-public information.) Saving the editbanned list or submitting an editlinks request requires the user to set their administrator password in Preferences.

When you use the Preferences page and give the Administrator Password, after hitting the Save button and navigating back to any wiki page, you'll see some new links at the bottom of every page. These are shortcuts (so you don't have to manually append text like "?action=foo" to URL's) for running various administrative Actions.

In addition to "admins", the wiki owner can also create a list of "editor" passwords. To use an editor password, type it into the "Administrator password" line on the Preferences page. The "editor" password(s) grant the ability to edit pages blocked by a global or edit-banned feature, but do not grant the ability to change the edit-locked status of the site.

The [UM9 test wiki] currently (April 2001) has an admin password of "test1234" for public testing of the admin features. Please feel free to try these features on that wiki. (The um9 wiki is a test site so it may occasionally be down when new features are tested.) Note that a valid admin password overrides the "global" edit lock or the editable banned list. (If you want to ban yourself you'll have to unset your admin password to see the effect. After testing you can re-enter your admin password and take yourself off the banned list.)

Special features (Actions) allowed if the user has an administrator password:

Maintenance runs *anytime*, not just once/12 hours. (Normal users can start the maintenance if the last run was at least 12 hours ago.)

Lock editing for all pages (only admins and "editors" can edit):

Unlock editing for all pages (everyone can edit):

These examples appear to be backwards. Doesn't editlock = 1 allow editing, and editlock = 0 prohibit it?

No, as far as I see it the above examples seems correct in usemod 1.0 --MarkusLude

Edit-ban list (first set your administrator password in Preferences):

Lock a single page (only admins (not even "editors") can edit that page):

Unlock a single page:

Rename or delete pages:

Possible Uses:

A "private" wiki site can email editor passwords to invited participants. Unlike an ordinary wiki, outsiders will not be able to damage the site if they find it (say, through a referrer entry in a log file).

An "invitation-only" wiki could have a single editor password given out to those who seem like good contributors. (Perhaps the site could ask for some background information or a proposed edit via email.) Another possibility is to put the editor password in a mission statement or FAQ list, ensuring that those who edit have some exposure to the site's documentation.

An individual can publish a wiki site without giving out edit access. (Not everything in the world needs to be collaborative.)

In a public wiki, a few people can use admin abilities to quickly limit possible vandalism, without requiring the presence of a site administrator. Also, trusted members of the community (almost all of them) can be given an editor password which allows them to edit even during most shutdown events.

A wiki can edit-lock a few core pages like RecentChanges, the front page, a few site-policy pages, and other things they feel are important. This may also make raw-HTML sites slightly safer by locking a set of commonly-read pages. (One could still attack a non-core page, but fewer people would read it.)

JerryMuelver -- If I do editlock, are new pages created under the editlock also editlocked, or do I have to re-apply the editlock?

The "editlock" action applies to the entire wiki, not any particular pages. (It creates a file called "editlock" in the data directory--if it exists, the entire wiki is locked.) The "pagelock" action locks only a single page by creating a page-specific lock file. These two kinds of locking are independent (if you remove the global "editlock" file, any pages locked with "pagelock" are still locked). --CliffordAdams

JerryMuelver -- Thanks, cliff.

RoSe? -- I tested um9test.pl using an admin pasword of "test1234". I locked a page(id=newlogin), and then banned myself. When I ran action=edit&id=newlogin, it told me that editing not allowed. However, when I ran action=browse&id=newlogin, I found there is a bar for Edit text of this page, and after I clicked this bar, I still can edit the page, and save it. Is there a bug??

I haven't been able to reproduce this problem. It is possible that you might have still had the admin password active in your preferences, since the admin password overrides any editing restrictions (locked pages or bans). --CliffordAdams

How do you edit and change the administration page so that you can lock the pages of my wiki??? Andy Tamlyn

What does "maintain" do?

The maintainance action (action=maintain) currently (in version 0.92) removes old versions of pages from the keep file if they are more than $KeepDays? old (default 14 days). In future versions the maintenance action may also permanently delete pages (using the MeatBall:DeletedPage convention) or update configuration files. --CliffordAdams

"Permanently delete?" Does that mean the older > KeepDays? files aren't deleted? The maintenance action does appear already to delete pages marked as DeletedPage, so maybe the "future versions" reference just above is out of date (v1.0 here)

Does KeepDays? grandfather (exclude from deletion) files already versioned before KeepDays? was first set >0? (KeepDays? seems not to be working for us.)

How does the KeepMajor? feature relate to this? If not 0, would that mean KeepDays? doesn't apply to major revisions? -mark krebs

Is it possible to lock the entire wiki with editlock and then unlock a few pages with pagelock to make it possible for anyone to change these? What I want is three levels of pages, admin pages, editor pages and public pages. Is it possible? I can't seem to get it to work. (Ie. I can't make the public pages editable for anyone.) -- JohanPeitz

This is not possible with the current code (0.92), and is not a planned feature for 1.0. The single-page unlock function simply removes any existing single-page lock file. I don't know of any easy way to do what you want here. --CliffordAdams

How about other files like editlock called something like overrideableeditlock and pageunlock? The test would then be

* if editlock then disallow edit
* else if pagelock then disallow edit
* else if pageunlock then allow edit
* else if overrideableeditlock then disallow edit
* else allow edit.

--pla

Ok, thanks. We donät have many non member visitors anyway. ;) -- JohanPeitz

Another question... How do I manage users? Can I delete a created user and replace his/hers id with another user? -- JohanPeitz

You could delete a user-ID file, but there is no (current or planned) way to reuse an old ID number. The "users" in UseModWiki are really just preferences (possibly including saved editor/admin passwords), so I don't see why you would want to delete them. --CliffordAdams

How exactly do I create accounts for editors once I have locked the pages? Do I do a relogin as a new user and create the accounts this way?

Oliver. http://www.carpe.com/wiki/

You don't really create accounts for editors. Instead you just give people the editor password, which they enter in their Preferences page. Once they enter a correct editor password they become editors. --CliffordAdams

Is there any harm having the pl in the same directory as the data? I have everything in /wiki and the data is in it's /mywikidb-subdir...

Oliver. http://www.carpe.com/wiki/

I don't see any harm in that. --CliffordAdams

If you try to use AdminFeatures, the admin and editor password will be visible as in http://www.carpe.com/wiki/config --AnonymousCoward

As you have to type in the fully qualified path name of the configuration file on most servers to view it, it would help to give the path/file a less obvious name than /wiki/config. --FrankRalf?

From my wish list wrt Wiki administration:

I often want to set up Wikis on systems where I am *NOT* an administrator.

A first issue this poses is wrt cgi-bin scripts -- many systems prefer to sharply restrict them.

User administration and security is the next major issue. Many sysadmins are not happy to have yet another password system providing access to parts of their system.

At least UseModWiki has passwords...

In my UNIX-centric imagination, for a limited usage model, I imagine users logging into my wiki iff they have a UNIX account and can enter the UNIX password. It would be even better if the files in the database could be restricted according to normal UNIX groups and permissions.

Actually, this is not really UNIX centric - same thing could apply to NT.

-- AndyGlew

Yikes! Making part of the web server validate against the unix passwords is a bad, bad, idea (as the Apache docs warn). It's OK if the only access is via https, otherwise usernames and passwords fly across the wire in clear text. Even on a server accessible only from the local network it's still a bad idea. Somebody can put his network card into promiscuous mode, suck up all those usernames and passwords and then trash those user accounts. Sooner or later somebody will get annoyed enough at something to do exactly that.

The editor and admin passwords do not give general access to the system running the UseModWiki CGI script--they just give access to a few more functions of the script. If one wants to restrict even view-only access, then I recommend using the password capabilities of the webserver (like Apache or IIS) to limit access to the script. --CliffordAdams

Why do I get error messages when I move files around (renaming), yet it moves the files anyway? The error messages I get are to the effect of the chnglog not being found or something bad happens and a file corrupts itself. Has anyone else had this problem? Better yet, does anyone have the solution?

This is probably a known minor bug in 0.92. The message says that the "oldrclog" file could not be opened. The oldrclog file is optional, but recommended for wikis with over 20,000 edits in the rclog (each line is a separate edit). (Briefly, one can split the rclog file by lines and put the older entries (at the beginning of the file) into the oldrclog file. The script will then only read the oldrclog file if needed.)

When I tested 0.92, I made sure to thoroughly test the move/delete/rename functions on a test wiki with lots of entries (a copy of the Meatball wiki). That wiki used an oldrclog file, and I didn't test the small-wiki case (with only the rclog file). This bug does not affect the move/rename/delete functions, and is fixed in my development code (which will become 1.0). --CliffordAdams

Is there some way to make a "private wiki", as mentioned above, more private such that it cannot even be viewed without a requisite password? I want this function for info to be shared by a subgroup that the larger group does not "need to know". -- Rory

There is no way to do this in the current code, and that feature is not planned for future releases. If you want to restrict even view-only access, then I recommend using the password capabilities of the webserver (like Apache or IIS) to limit access to the script. --CliffordAdams

Maybe an interesting idea might be to have the wiki optionally rely on the webserver's password capabilities instead of a cookie? Additional code could be written to have the wiki synchronize its accounts and the .htaccess automatically for those who can grant the required permissions to the script. That way, it could integrate seamlessly with the server auth features. Sound like an idea? Of course, I have no real clue - I've just come across UseModWiki and am still only exploring the information. </disclaimer> -- Aristotle

I also need this option of 'private wiki' with password to view, and i have no access to the apache server config. so above comment would not be an option for me, there's really no workaround ? -- Matt

Matt: If your Apache server permits, you can put a .htaccess file in your own directory to modify how the server will handle that directory. See the Apache docs at http://www.apache.org/.

Is there an easy way to reactivate old revisions or just taking back some edits?

There is only the hard way. See other revisions, view the one you want, edit it, save the page. -- AlexSchroeder

How can one make IPs of editors in RecentChanges visible to admins only? Having IPs out there in the open to anyone is a Bad Idea.

Why is this a Bad Idea? Showing your IP address is how the Internet works. You do it every time you request a web page, send an email, or anything else. Personally, I kinda like having the IP address show up, as it helps me quickly track down which country the latest spammers are coming from (Yesterday it was Ireland. Before that, Australia. Before that, Russia. And Mexico before that!) and to quickly ban their network, but also point out in comments just where the worst bottom-feeders are coming from. --PatrickSalsbury 

 To answer myself- this is just a quick workaround, i'll try to think of a way to do this with user authentication, so that admins cann see user IPs.
will post patch when done. 

 Is the code below the quick workaround? If so, which part of wiki.pl do I add it to? Thanks. - BrendanTregear

#hide $host
   $host = &QuoteHtml($host);
    if (defined($extra{'name'}) && defined($extra{'id'})) {
    #  $author = &GetAuthorLink($host, $extra{'name'}, $extra{'id'});
#$author=&GetAuthorLink($extra{'name'},$extra{'id'});
$author="registered user";
} else {
#      $author = &GetAuthorLink($host, "", 0);
$author= "anonymous";

How can I add a new link to the link bar at the top and bottom?

Look at the question "Edit the header" on the UserHelp page.

How can I roll back a revision of a page?

Yes, it is time-consuming, but I didn't have time to implement a better method. (I had originally hoped to make it easy for admins to roll back one author at a time, but it isn't trivial to code.) --CliffordAdams
I would like to put the Search box at the top, or both top and bottom. Well actually I want to freely edit both header and footer but I don't seem to have access to html though I thought I'd enabled it.
I have installed the Wiki (private wiki) initially without adminpassword and later modified the config file to enable admin pages. But, I do not see the admin links showing up in the page although I have set preferences to use admin password. I also do not see the modified SiteName? string. What should be done to reload the config changes? --Selva

First of all, make sure that the config file is in the $DataDir directory. You may need to make it world-readable (the command "chmod ugo+r config" will do this on Unix-based systems). Also, if there is an error in the config file, it will stop processing at the point of the error. You might want to go into the code where it says: 

        # Uncomment the line below if you want to catch use strict errors.
#       $ConfigError = T('Unknown Error (no error text)');

... and change it to: 

        # Uncomment the line below if you want to catch use strict errors.
        $ConfigError = T('Unknown Error (no error text)');
...removing the '#' character from the second line. This will make the wiki report certain errors in the config file that might otherwise not be found. (The most common errors are not closing quotes correctly and forgetting the semicolon ';' character at the end of each line.)

If you suspect an error within the config file, a good way to find it is to start by adding a line like: 

$SiteName    = "TestingHere";

...to the *start* of the config file. Then rerun the wiki and see if this change is effective (it is effective if the site name is "TestingHere?"). If it works, move the SiteName? line to a lower position in the file. When the change stops working, the error is between the previous position and the current position.

If this doesn't work, perhaps you could send me (usemod@usemod.com) your config file and I will look for errors. --CliffordAdams

ouch. I missed placing the config file in $DataDir. It works fine now with admin links showing up. To avoid showing the admin password inadvertantly I've setup apache folder access login (using the htpasswd.users file and such) and have decided to use the config parameters within the wiki.pl file itself instead of a config file. Great Wiki! thanx. --Selva.

It is reassuring to see that my UseMod wiki is not the only one being pummeled by the shop263 Asian spammers who returns on a daily basis to insert their links. IP banning is not really working that well. At least they stuff it in the bottom. -- AlanL?

It shouldn't be too terribly hard to put some protection in, but any comprehensive protection is going to require some extensive source hacking. I'm starting to think that a community site may now have to go with community moderation. At the very least, the googlebot is going to have to be prevented from crawling pages with unmoderated changes. -- ChuckAdams

Thanks- I do not want heavy handed protection, but I cannot even seem to get the IP ban strings to work based on the examples. Is there an idiots guide to writing the expressions? I am getting a suite from 221.xxx.xxx.xxx, 219.xxx.xxx.xxx, 60.xxx.xxx.xxx.... and would not mind just shutting them down from the top. II have now: 

  ^210\.82\.106\.\d+$
  ^221\.147\.20\.\d+$
  ^221\.198\.74\.\d+$
  ^219\.233\.53\.\d+$
  ^60\.25\.123\.\d+$
  # let's try to block all of these
  ^210\.\d+\.\d+\.\d+$
  ^221\.\d+\.\d+\.\d+$
  ^219\.\d+\.\d+\.\d+$
  ^60\.\d+\.\d+\.\d+$

These buggers return almost daily to a wiki set up to introduce educators to how great wikis are for collaborative spaces -- AlanL?

Those blocks should work. The set after the comments in fact makes the first set redundant. It looks like UserIsBanned?() is getting the connection address from environment variables however, which is virtually guaranteed to not work in mod_perl or other persistent environments. Are you running in such an environment? --ChuckAdams

Thanks (you are quick). I may have had typos initially, forgetting a forward slash. I wanted to make sure the broader ones were okay. How would I know how UserIsBanned? is getting the connection address? This is not running in mod_perl or anything fancy- I think it is a vanilla Linux 7.x. -- AlanL?

What's the point of being able to set a password in the preferences, when you can set your user name to an existing one in the preferences without specifying the correct password? E.g., I have set my username to CliffordAdams, which is also the name that appears in the diff. Now, people could post very rude (best case) or illegal (worst case) things under someone else's name. Why isn't the password/username combination checked to at least prevent people from editing pages using other users' names?

This question is a follow up to the password-protected private wiki discussion abive. I'm running on MacOS? X and set up user authentication as outlined at http://www.apacheweek.com/features/userauth which works for normal html pages, but I am unable to protect the perl script itself. Has anyone successfully set up a private wiki with this feature? -- Hodelas

How do you do this for normal html pages, with .htaccess file or restrictions in the global server config file? For the first, did you try to put a .htaccess file in the same directory as the wiki script or what did you try?

The instructions at the apache page above tell how to set up user lists, passwords, and htaccess files. I don't know why the .htaccess files worked for normal html and not the wiki.pl script. However, after looking at other examples, I found this solution (working under Mac OS X). Create a subdirectory in the cgi-bin directory (I called mine "pass") and then add this code to the end of httpd.conf: 
<Directory "/Library/WebServer/CGI-Executables/pass">
  AuthType Basic
  AuthName "Users Only"
  AuthUserFile /Library/WebServer/.htpasswd
  Require valid-user
</Directory>
That did the trick.

Strange. Usually you shouldn't need this extra directory and place the .htaccess file in the same directory as the wiki script. But I'm not familiar with Mac OS X. --MarkusLude
UseModWiki | RecentChanges | Preferences
Edit text of this page | View other revisions | Search MetaWiki
Last edited September 13, 2016 6:43 pm by JuanmaMP (diff)
Search: