use IkiWiki::Setup::Standard {
wikiname => "MyWiki",
#adminuser => ["yourname", ],
+ adminemail => 'me@myhost',
# Be sure to customise these..
srcdir => "/path/to/source",
# Whether to integrate with svn.
svn => 1,
svnrepo => "/svn/wiki",
+ svnpath => "trunk",
wrappers => [
{
# what you want.
wrapper => "/svn/wiki/hooks/post-commit",
wrappermode => "04755",
+ # Enable mail notifications of commits.
+ notify => 1,
},
#{
# # The cgi wrapper.
--- /dev/null
+ikiwiki now supports subscribing to pages on wikis with a subversion
+backend. Subscribers will be mailed commit diffs.
+
+Some changes are needed to ikiwiki configs to support this:
+
+* A new `--adminemail` config option has been added, that is used for both
+ this and for sending user subscription mails, so should be configured on
+ any wiki that uses either feature.
+* `--svnpath` needs to be set to location of your wiki inside its
+ subversion repository. It defaults to "trunk", which will work for many
+ layouts.
+* A new `--notify` config option should be passed to ikiwiki when it's run
+ as a svn commit hook, to enable it sending the subscription mails.
+* `--svnrepo` is actually supported and used now, so should be set to the
+ subversion repository directory.
+
+[[ikiwiki.setup]] has been updated accordingly.
+
+This is the last major change planned before the first official release of
+ikiwiki. The main remaining issue blocking that release is the resolution
+of what to do about HTML XSS [[security]] issues.
ikiwiki does not expose untrusted data to the shell. In fact it doesn't use
system() at all, and the only use of backticks is on data supplied by the
-wiki admin and untainted filenames. And it runs with taint checks on of course..
+wiki admin and untainted filenames. And it runs with taint checks on of
+course..
## cgi data security
# Fixed holes
-_(Unless otherwise noted, these were discovered and immediatey fixed by the ikiwiki developers.)_
+_(Unless otherwise noted, these were discovered and immediatey fixed by the
+ikiwiki developers.)_
## destination directory file replacement
--- /dev/null
+Should support mail notification of new and changed pages.
+
+ Hmm, should be easy to implement this.. it runs as a svn post-coommit hook
+ already, so just look at the userdb, svnlook at what's changed, and send
+ mails to people who have subscribed.
+
+ A few details:
+ 1. [[Joey]] mentioned that being able to subscribe to globs as well as
+ explicitly named pages would be desirable.
+ 2. I think that since we're using Perl on the backend, being able to
+ let users craft their own arbitrary regexes would be good.
+
+ Joey points out that this is actually a security hole, because Perl
+ regexes let you embed (arbitrary?) Perl expressions inside them. Yuck!
+
+(This is not actually true unless you "use re 'eval';", without which
+(?{ code }) is disabled for expressions which interpolate variables.
+See perldoc re, second paragraph of DESCRIPTION. It's a little iffy
+to allow arbitrary regexen, since it's fairly easy to craft a regular
+expression that takes unbounded time to run, but this can be avoided
+with the use of alarm to add a time limit. Something like
+
+ eval { # catches invalid regexen
+ no re 'eval'; # to be sure
+ local $SIG{ALRM} = sub { die };
+ alarm(1);
+ ... stuff involving m/$some_random_variable/ ...
+ alarm(0);
+ };
+ if ($@) { ... handle the error ... }
+
+should be safe. --[[WillThompson]])
+
+ It would also be good to be able to subscribe to all pages except discussion pages or the SandBox: `* !*/discussion !sandobx`, maybe --[[Joey]]
+
+ 3. Of course if you do that, you want to have form processing on the user
+ page that lets them tune it, and probably choose literal or glob by
+ default.
+
+ I think that the new globlist() function should do everything you need.
+ Adding a field to the prefs page will be trivial --[[Joey]]
+
+ The first cut, I suppose, could use one sendmail process to batch-mail all
+ subscribers for a given page. However, in the long run, I can see users
+ demanding a bit of feature creep:
+
+ 4. Each user should be able to tune whether they see the actual diff parts or
+ not.
+ 5. Each user should be able to set a maximum desired email size.
+ 6. We might want to support a user-specified shibboleth string that will be
+ included in the email they receive so they can easily procmail the messages
+ into a folder.
+
+ --[[BrandenRobinson]]
+
+ I'm deferring these nicities until there's some demonstrated demand
+ --[[Joey]].
+++ /dev/null
-Should support mail notification of new and changed pages.
-
- Hmm, should be easy to implement this.. it runs as a svn post-coommit hook
- already, so just look at the userdb, svnlook at what's changed, and send
- mails to people who have subscribed.
-
- A few details:
- 1. [[Joey]] mentioned that being able to subscribe to globs as well as
- explicitly named pages would be desirable.
- 2. I think that since we're using Perl on the backend, being able to
- let users craft their own arbitrary regexes would be good.
-
- Joey points out that this is actually a security hole, because Perl
- regexes let you embed (arbitrary?) Perl expressions inside them. Yuck!
-
-(This is not actually true unless you "use re 'eval';", without which
-(?{ code }) is disabled for expressions which interpolate variables.
-See perldoc re, second paragraph of DESCRIPTION. It's a little iffy
-to allow arbitrary regexen, since it's fairly easy to craft a regular
-expression that takes unbounded time to run, but this can be avoided
-with the use of alarm to add a time limit. Something like
-
- eval { # catches invalid regexen
- no re 'eval'; # to be sure
- local $SIG{ALRM} = sub { die };
- alarm(1);
- ... stuff involving m/$some_random_variable/ ...
- alarm(0);
- };
- if ($@) { ... handle the error ... }
-
-should be safe. --[[WillThompson]])
-
- It would also be good to be able to subscribe to all pages except discussion pages or the SandBox: `* !*/discussion !sandobx`, maybe --[[Joey]]
-
- 3. Of course if you do that, you want to have form processing on the user
- page that lets them tune it, and probably choose literal or glob by
- default.
-
- I think that the new globlist() function should do everything you need.
- Adding a field to the prefs page will be trivial --[[Joey]]
-
- The first cut, I suppose, could use one sendmail process to batch-mail all
- subscribers for a given page. However, in the long run, I can see users
- demanding a bit of feature creep:
-
- 4. Each user should be able to tune whether they see the actual diff parts or
- not.
- 5. Each user should be able to set a maximum desired email size.
- 6. We might want to support a user-specified shibboleth string that will be
- included in the email they receive so they can easily procmail the messages
- into a folder.
-
- --[[BrandenRobinson]]
Specify a mode to chmod the wrapper to after creating it.
+* --notify
+
+ Enable email notification of commits. This should be used when running
+ ikiwiki as a [[Subversion]] [[post-commit]] hook.
+
* --svn, --nosvn
Enable or disable use of [[subversion]]. If subversion is enabled, the
Subversion is enabled by default.
+* --svnrepo /svn/wiki
+
+ Specify the location of the svn repository for the wiki. This is required
+ for using --notify with [[subversion]].
+
+* --svnpath trunk
+
+ Specify the path inside your svn reporistory where the wiki is located.
+ This defaults to trunk; change it if your wiki is at some other location
+ inside the repository.
+
* --anonok, --noanonok
If anonok is set, it will allow anonymous web users, who have not signed in, to make changes to the wiki.
"\[[file]]" is replaced with the file to browse. It's common to use
[[ViewCVS]] for this.
+* --adminemail you@yourhost
+
+ Specifies the email address that ikiwiki should use for sending email.
+
* --diffurl http://svn.someurl/trunk/\[[file]]?root=wiki&r1=\[[r1]]&r2=\[[r2]]
Specifies the url to link to for a diff of changes to a page. In the url,