configure to overlay defaults from site

[WardCunningham]

The wiki-server has a default-data directory where a few bootstrap pages like welcome-visitors and how-to-wiki reside. This pull request adds a configuration parameter defaults which specifies a particular site on the server where additional bootstrap pages can be found. These overlay the existing default-data pages so a customized welcome-visitors can be provided. Also the defaults can be specified per wikiDomain if customizations are to vary with each of these.

Here is a sample config.json where only some of the subdomains use the overlay defaults.

{
  "admin": {"google":"105504...7852"},
  "farm": true,
  "port": 3000,
  "cookieSecret": "0934508...3453",
  "security_type": "passportjs",
  "google_clientID": "72587....googleusercontent.com",
  "google_clientSecret": "Xf9P...fkQ",
  "wikiDomains": {

    "localhost": {},

    "open.localtest.me": {
      "restricted": false
    },

    "closed.localtest.me": {
      "restricted": true
    },

    "localtest.me": {
      "restricted": true,
      "defaults": "/Users/ward/.wiki/defaults.localtest.me",
      "allowed_domains": [
        "dayton.k12.or.us",
        "innovateoregon.org",
        "c2.com"
      ]
    }
  }
}

Here is a new localtest.me site where the overlay welcome shows after login to view.

Some further considerations.

• [ ] It is awkward to have to specify a full path but that avoids the farm logic from changing it
• [ ] Perhaps the Login to View page should be in default-data and subject to overlay

[paul90]

This changes the page search from:

wiki -> server default pages -> plugin pages

to:

wiki -> configured default pages -> server default pages -> plugin pages

This looks good.

Maybe the Login to View page should move to the security adapter pages, it could then be simply overridden by one in a configured set of default pages. And also simplified configuration by removing details parameter.

[paul90]

To avoid adding the full path to in for the defaults, it would be nice to say something like:

"defaults": "defaults.localtest.me",

Is it an acceptable limitation that the defaults have to come from a site that is part of the current farm? I think it is, as we then avoid needing to make a network request to see if the page exists, and also we don't need to be concerned about what if the default site is itself restricted.

For the construction of the file path for the potential default page we could use argv.db which defaults to #{argv.data}/pages *it is reasonably safe to assume that we will only ever see the default - anything else would likely need changes to the farm code.

The value of argv.data will need to be picked up in the context of the defaults wiki...

[WardCunningham]

I like the idea of,

"defaults": "defaults.localtest.me",

I tried to make that work but couldn't figure out how to compute the proper paths. My technique was to return argv along with other data as follows:

res.json {roll, files, argv}

By the time the server-side plugin sees argv the argv.data field has been adjusted for the farm site. Every other file name field has been adjusted too. (I removed argv from the return before publishing to npm as there is information in argv that shouldn't leave the server.)

I'm anticipating lots of distinct subdomains with different allowed_domains and I haven't got the current code working quite right as is. (My matching logic sees too deeply into subdomains.)

[paul90]

A change to use the name of the wiki to use for defaults, rather than a full path.