UploadablePlugins

Motivation

As I was answering the questionnaire for Peter's book, I realized that one of my biggest annoyances is that TWiki doesn't have UploadablePlugins. To install a plugin you have to be the wiki administartor. Which often I am; but often I ask IT to administer the wiki, and when they do I am not allowed to install plugins, because installing plugins could give me access to other user's Windows passwords...

So, I really want UploadablePlugins. However, not clear if uploadable Perl plugins would fly in my ennvironment, unless they were sandboxed in much the same way Java, and to a lesser extent JavaScript, is sandboxed. The reason I don't administer these wiki sites, apart from hassle avoidance on my part, is that IT doesn't want non-IT sysadmins accessing critical CGI scripts.

The rest of this page is a riff on using JavaScript for UploadablePlugins. Needs refactoring.

JavaScript for UploadablePlugins

What does this have to do with enabling or disabling JavaScript? Well, since I have encountered at least one wiki completely written in JavaScript, it is obvious that a lot of functionality can be implementedin JavaScript, and do not require Perl.

For example, my favorite plugin, TREEVIEW, could be implemented totally in JavaScript. The JavaScript could find all the pages in a wiki web via the web interface, and then do the TEEEVIEW proccessing. That might be making an already slow plugin even slower - one of the advantages of server side Perl plugins over client side JavaScript is that they can access the local filesystem. But it might motivate a more efficient general solution - e.g. caching the TREEVIEW in a wiki page, with an update button.

JavaScript for UploadablePlugins

Probably the path of least resistance would be to write UploadablePlugins in JavaScript. Already the user can place JavaScript in a wiki page, which may or may not be a security hole. See GetRidOfJavaScript

I am not aware of any other scripting language that is universally available in web browsers. I prefer Java... but JavaScript is ubiquitous.

Like many security minded people I often disable JavaScript. And certainly I run sandboxed. But I might be willing to relax these permissions in order to get UploadablePlugins.

Clientside vs Serverside

One objection to UploadablePlugins would be whether they could break wiki server security.

This is partially addressed by running the plugin on the client. The client plugin then cannot access anything the webbrowser cannot already do. It could be a Trojan fooling the client user.

One reason for suggesting JavaScript for Uploadable plugins is that JavaScript most naturally runs clientside.

Serverside JavaScript exists. If clientside Javascript plugin performance is an issue, it could be moved to serverside JavaScript. I would probably want to run such uploaded JavaScript thouroughly sandboxed on the server, however, for security.

Serverside JavaScript plugins might have some security value over clientside, but trojans would still be an issue.

Is the Infrastructure Already Here for UploadablePlugins using JavaScript?

• we can place JavaScript in wiki pages
• we can edit that JavaScript
• Q: is there any way that JavaScript on one wiki page can call JavaScript on another wiki page as a function or module?

Embedding Calls to UploadablePlugins

If called directly, no problem.

However, we would probably want the UploadablePlugins to add things such as new TWiki %-variables and %-functions.

This might be accomplished via a wiki-editable table that mapped %-stuff to the appropriate calls to whichever UploadablePlugins are wanted. This table could be handled as is usual in TWiki: global, per-wiki-web, and per-user. see the next section.

Security for UploadablePlugins

How could you trust a wiki system using UploadablePlugins?

By default, do NOT allow others to execute a plugin uploaded by somebody else.

If a %-word or %-function is encountered that is handled by UploadablePlugins not currrently active, warn the user, and ask him if he wants to actiivate the plugin. Track uploadable plugin activation on a per-user basis.

Allow the wiki administrator to enable some globally. Ditto per web.

-- AndyGlew - 15 Jul 2005

I'm glad you raised this. It's not well publicised, but there has been discussion (mainly on IRC) regarding support for installation of perl plugins from the configure interface. That way the installing person only needs the TWiki configuration password, and doesn't need webserver login access. More and more plugins are shipping with BuildContrib support, which allows hands-off dependency resolution. The advantage of this approach is that a minimum of new infrastructure is required to support install many of the wealth of existing plugins.

Of course there are huge problems with perl plugins:

• some plugins I wouldn't trust to stand upright. Innocently uploading a plugin could expose your server to hackers, or even take it out completely. There has to be some sort of certification scheme for plugin authors or plugin modules (this was mooted by PeterThoeny)
• access control. Making plugin access selectable by using is mooted in AccessControlLists, as they are (should be) resources, same as webs and topics and attachments.
• by the very nature of the language it is very hard to sandbox a piece of perl. As we have seen, modules outside the core are freely calling core functions. Unfortunately due to history, they have been forced to do so to get the job done, but it does mean that the definition of a "pure plugin" is so weak as to be useless. At least we have the analyse_plugins script to determine how pure a plugin really is. From what I know of Javascript, it would suffer from the same problem; it is much weaker in this resepct than, say, Java.

There are problems with the idea of Javascript plugins as well, of course. I have been exposed to some fairly hairy Javascript (admittedly all client-side) while working on the WysiwygPlugin Kupu integration. I really can't recommend it as an implementation language for anything very much. It also doesn't fit very well with the TWiki architecture. Having said that, I would be very interested to see what sort of plugins you think we could do this way; some of the more obvious ones are (as you mention) TreeView, TablePlugin, EditTablePlugin, and many simple text filters. Are there enough of these types of plugin to justify the effort required to build such an infrastructure?

-- CrawfordCurrie - 16 Jul 2005

One of the attractions of Javascript uploadable plugins is that the Javascript has a chance of being useful for more than just wiki. E.g. if I created a text filter that allowed a list of HTML URLs to be concatenated and printed nicely, it might be generically useful, not just for wiki. Conversely, such Javascript code can be imported from other applications.

This being said, I agree that there is major hairyness with Javascript security. However, it looks as if I can run fairly arbitrary Javascript on the existing wiki (at least on my several years old IT managed wiki installation). So all of the potential Javascript security holes are real. I suppose that they are mainly avoided by security conscious people not having Javascript enabled. The question is whether the infrastructure needed so that people could trust Javascript shoulkd be built.

As for the language (a) I don't like Javascript (b) but some pretty big apps have been built in it. See Mozilla.

-- AndyGlew - 19 Jul 2005

See MoreWebBasedTWikiManagement

-- AndyGlew - 19 Jul 2005