A single notification subscription for multiple Webs?

What if we add a AllWebNotify topic for people interested in all webs contained in the TWiki?

It should be easy/immediate ... just add an option (web=all) to the search call in mailnotify ...

-- AndreaSterbini - 22 Jan 2001

The script mailnotifyall and the related template mailnotifyall.tmpl implement a new strategy for the notification of changes on TWiki pages. The script, derived from the mailnotify script, does the following:

• Sends one email to notify all the changes from all the webs.
• The notification list is taken from the Main.WebNotify page.

To install:

• cd to the TWiki HOME directory (/home/apache/twiki/ for example).
• extract the compressed-tar file.
• add an entry to the crontab like (refer to the mailnotify installation):

     0 7,11,16,20 * * * (cd /home/apache/twiki/bin; ./mailnotifyall -q)

Note: the new strategy can live with the old one (mailnotify), but the Main.WebNotify page role is specialized, when mailnotifyall is used.

-- BrunoFranzini - 18 Jul 2002

What version of mailnotify is it based on?

Could possibly be merged into the mailnotify script, and acivated by a command line switch.

-- PeterThoeny - 18 Jul 2002

mailnotifyall is based on mailnotify version 1.18 (the one with the "TWikiRelease01Dec2001" TAG). I will check and merge more recent changes.

The script can be merged easilly (I'll do it as soon as possible), but not the template (I believe).

-- BrunoFranzini - 19 Jul 2002

This looks really useful - has anyone patched/ported this to Beijing release?

-- MichaelSparks - 14 Jun 2003

I haven't checked the code, but I imagined lst night that there could be security holes here - which matter, for sites like mine, where some webs contain quite sensitive company data.

Basically, mailnotifyall coould very easily allow users who are not allowed to look at a web to see

• topic page titles
• summaries or diffs

depending on how many other mail extensions are used.

Even the titles of pages could be considered secret. Such as PlanToExecuteHostileTakeoverOfCompayXXX. My apologies if mailnotify already does this sort of checking.

I have the converse of this problem: because I do not trust TWiki security, I depend on setgid cgi scripts and webserver security - yes, it's not the best, but is one thing my sysadmins know how to administer. Different webs are not accessible to each other. Most users cannot access all of the webs at one time. (There is one user (me, and, I suppose, root) who can access all the webs, but I would prefer not to have the mailnotify script run as that user.)

I therefore need to run the mailnotify scripts on a web by web basis (or, actually, a security level by security level basis).

-- AndyGlew - 24 Jun 2003

Interesting point. Taking a cursory check on the code this does look like a problem with this script. The only people it affects as a security hole are people who block entire webs from being viewed by groups of people. That said, this isn't necessarily an uncommon requirement. (Only allowing access/knowledge of the contents one of our webs from the rest of the organisation has recently been raised by a new user. In this particular situation, the name of the topic could be considered sensitive information)

By definition, this problem also potentially affects LogicallyNestedWebs that allow topic inclusion from other webs. (Unions/importing of webs) In order to do this "correctly" you need to either collate people's notifications, or build them on a user by user basis. The former is probably more practical.

-- MichaelSparks - 24 Jun 2003

I'll make my "stuck record" sound: if you think of TWiki as a web interface to a filesystem, logical nesting, hierarchy, etc., all fall out with well understood consequences.

Nested webs have a "path" from the filesystem root to their end. A user request should be checked against the access controls on each element of the path.

Unions/importing of filesystems are less common in real OSes, although they are familiar to anyone who has read Korn's papers. Typically, you might consider them to be implemented by a flavour of symbolic link, whether a UNIX symlink or a Windows shortcut or a special file mapping entry... the appropriate way to handle such permissions is, again, to walk down the path, comparing the user request to the access controls of each path element; when a link is encountered, start the process again.

Tools like mailnotify are really performing a whole slew of requests on behalf of a whole slew of users; they need to consider the permissions of each user.

-- AndyGlew - 25 Jun 2003

mailnotifyall does�t seem to work with mailnotify. I installed mailnotifyall script and have following crontab entries.

0 6 * * * cd /home/twiki/bin;./mailnotifyall -q
5 6 * * * cd /home/twiki/bin;./mailnotify -q

In this case mailnotify doesn�t send out any email. If I schedule mailnotify before mailnotifyall then mailnotifyall doesn�t send any email. I suspect that whichever script runs first marks topics as �sent� and therefore the later script doesn�t pick them up because they are already marked �sent�. Did anyone else noticed it or is it just me?

-- HaritNanavati - 28 Oct 2003

I think I know what is happening. Both scripts look at file $webdir/.mailnotify to check when last notify happened. Both scripts then consults $webdir/.changes to figure out what topics changes to include. And finally update file $webdir/mailnotify with the current time. And that�s why whichever script runs later won�t include any changes that previous script had already notified. I think the fix would be to keep a separate file $webdir/.mailnotifyall for mailnotifyall script. Following is the diff for this change

96c96
<             $prevLastmodify = &TWiki::Store::readFile( "$dataDir/$webName/.mailnotify" ) || "0";
---
>             $prevLastmodify = &TWiki::Store::readFile( "$dataDir/$webName/.mailnotifyall" ) || "0";
186c186
<             &TWiki::Store::saveFile( "$dataDir/$webName/.mailnotify", $currLastmodify );
---
>             &TWiki::Store::saveFile( "$dataDir/$webName/.mailnotifyall", $currLastmodify );

-- HaritNanavati - 28 Oct 2003