pass app to plugins to add routes

[WardCunningham]

Caution: I've yet to successfully build this module.

This pull request adds app to the parameters passed to a server-side plugin. This allows the plugin to add routes for restful service to the client-side plugin. Until now we have used websockets for this communication.

The Shell plugin provides an example of this in use. github

As mentioned above, I'm having trouble building this module such that it can be npm-linked into a current install of wiki. I've successfully hand patched this functionality into wiki's installed version but a build from source gives this error on startup. I'll need some help diagnosing this.

node index.js -p 3020

 Error: Cannot find module 'wiki-security-persona'
  at Function.Module._resolveFilename (module.js:336:15)
  at Function.Module._load (module.js:286:25)
  at Module.require (module.js:365:17)
  at require (module.js:384:17)
  at module.exports.exports (/Users/ward/FedWiki/wiki-server/lib/server.js:133:43)
  at Object.<anonymous> (/Users/ward/FedWiki/wiki/cli.coffee:133:9)
  at Object.<anonymous> (/Users/ward/FedWiki/wiki/cli.coffee:1:1)

[paul90]

Caution: I've yet to successfully build this module.

Are you sure you have the persona plugin installed in the wiki server you're using for testing?

[WardCunningham]

I have been motivated to empower server-side plugins this way in order to expose my neo4j graph of the federation without exposing the full power of its query language to possible abuse. The server-side would provide the client with trusted queries where only parameters arrive from the client.

[WardCunningham]

I've cloned and installed wiki-server from master, made my change, built and shared with npm link. From a fresh install of wiki I can toggle my wiki-server build in and out with these two commands.

npm link wiki-client
npm install wiki-client

One works, the other doesn't. The wiki-security-persona module is untouched by these commands. I understand that npm-link is not a complete duplicate of publication and install but I would think that the linked version would be more likely to work, not less. I suspect this will require more exploration than easily coordinated here. But, hey, I'm often surprised what little things I miss.

[WardCunningham]

On a related issue, I was unable to reach into either req or app to get at my authentication/authorization state from the plugin. I'd like to develop some templates for appropriate checks thinking that we could then write plugins providing a better server administration interface. This could range from selecting themes to creating subdomain sites.

One capability that eludes me is establishing that a logged in user is the responsible operator of the server. Site owner isn't the same as server owner. Maybe we should have a server parameter identifying the true server owner?

[paul90]

Maybe we should have a server parameter identifying the true server owner?

That sounds like a good idea.

On a related issue, I was unable to reach into either req or app to get at my authentication/authorization state from the plugin.

A number of things are available:

res.session will contain the current session state - it will be empty if the uses is not logged in, but with the current Persona scheme will contain the email address of an authenticated user res.session.email.

app.securityhandler is also available. owner is not exposed by the server but app.securityhandler.retrieveOwner will get owner (currently just the email address). While app.securityhandler.isAuthorized(req) can be used in the route to check that either the user is the owner, or the site is not owned.

I suspect that with adding an identifier for the server (farm) owner that there will be a need to extend calls in the securityhandler. I expect future authentication will use something other than email to identify the user, though it should still be part of an owner's profile, so hard coding the use of email into the core is best to be avoided.

[WardCunningham]

@paul90, this is probably the advice I needed to protect the Shell plugin. I was experimenting with securityHandler trying to duplicate logic in wiki-server. I will follow one or more of these paths and improve this PR.

I'm still stuck getting wiki-security-plugin to load. Any tips for debugging? I'll just insert console.logs unless you can suggest better technique.

[paul90]

You can always try using wiki -v or node index.js -v to check what is installed - the security plugin should be listed before the other plugins, and be in wiki's package.json and node_modules directory.

[WardCunningham]

I apologize for the long transcript. Here I run my linked version which fails, check with -v that there is a wiki-security-persona, then install a known-good wiki-server from npm, check that it reports the same -v, and then show that it starts. I can dig deeper but don't have time to at the moment. Soon.

nr:wiki ward$ node index.js -p 3020

 Error: Cannot find module 'wiki-security-persona'
  at Function.Module._resolveFilename (module.js:336:15)
  at Function.Module._load (module.js:286:25)
  at Module.require (module.js:365:17)
  at require (module.js:384:17)

(remainder of typescript redacted)

[paul90]

Ah, we saw this some time ago. When you use npm link the search gets confused when trying to resolve peer dependencies. In wiki-server it will look for the security plugin in the wrong place, where it is linked in from /usr/local/lib/node_modules/wiki-server, rather than where it is linked into. There are a number of issues over in the npm repo about peerDependency issues like this, but as many have been open for a while...

I notice that some are solving this by using require.main.require(....)

[paul90]

Three commits from working with Ward on the 23rd Jan.,

We add a new question to the security handler, so we can restrict some actions to just an authenticated wiki farm administrator - as there is no way of authenticating with the default handler it is always false here.

We alter the main get route to not process urls where the first element is plugin, so they can get picked up by a route added in a plugin server component.

I also remove the optional ws dependency, as it is not used anywhere.