#pragma secure

Whenever a page which is tagged with '#pragma secure' is accessed it is checked if the protocol is https, if the protocol is http then moin yields an automatic redirect to the same page served by https.

Secure pages are NEVER transported over insecure links.

There might even be a client certificate validation and the page will only be served to registered clients (needs to be worked out) example: #pragma secure([SomeUser,SomeotherUser]). See also the patch on SF patch tracker.

-- cehteh 2004-04-05

Multiple AUTH_TYPEs

In request.py on line 123 (in the 1.2.1 distribution) it specifically checks for and AUTH_TYPE of Basic. Unfortunately, this turns out to be too limiting. mod_pubcookie, for example, allows setting arbitrary AUTH_TYPEs, yet still fakes Basic authentication. The question then becomes, should we merely check that AUTH_TYPE is set and not empty, or should we create e.g. config.auth_types = ['Basic',] and then use in to test for membership?

It turns out there is another complication here: user preferences with ACLs. It's currently impossible (AFAICT) to successfully use user preferences with auth_http_enabled and ACLs. Or at least it is in my environment. Because we're using Kerberos as the underlying authenticator for mod_pubcookie, we get userids that look like, e.g. geek@ANDREW.CMU.EDU. The use of ACLs enforces the WikiName format for userids. That said, creating ACL groups (and referencing them) seems to work just fine when they contain these long usernames.

ACLs for history

There should be a way to All: read but forbid history viewing. On private wiki's this would help alot, as if you posted something than removed it so nobody else can see what you've removed.

You can patch the code to achieve this in the mean time. Edit the file */pythonX-X/site-packages/MoinMoin/theme/__init__.py. Find the shouldShowEditbar function. At the beginning of the function add the following lines:
```
   1     def shouldShowEditbar(self, page):
   2         ...
   3         if not (page.isWritable() and
   4                 self.request.user.may.write(page.page_name)):
   5             return False
```
This prevents it to display the info, actions, attachments, etc. for those who do not have write permit. It is especially useful for private websites such as your own homepage. --- SalihErgut Date

ACLs should be considered in the history

Only those revisions of a page should be visible in the history (or "diffable" in the page's own history), that the user has rights to.

If I privately edit a page, that is tagged "#acl All:", and later on publish the page by removing the #acl-line, then every user can also see those revisions, which were still tagged.

Executor Bit for Parsers

MoinMoin plugins for GnuPlot and LaTeX etc. execute external commands. That is highly insecure because, for example, GnuPlot allows access to the shell. One could, of course, deny the execution of these external commands if the request has not been done by an admin (request.cfg.superuser). The problem then is that unauthorized (non-admin) users may change a page and an admin user may accidentally execute that code by requesting that page. To avoid that, a solution would be to implement a check at the page submission/edit stage to ensure that text parts to be executed by parsers for which the executor bit is set do not get changed by non-admin users.
A simpler solution would be to check new pages for corresponding parser entries and disable/remove them if the page is submitted by a non-admin user.
The probably simplest solution would IMHO be to check if a page may be edited by a non-admin user. (How do I do that?) The executor bit would then prevent the parser from being called for such pages. The parser output could be replaced by 'page permissions not restrictive enough for parser xxx'.

All these principles are doomed to fail in a wiki ... the correct way is to fix the parser of course. JohannesBerg put serious efforts into making the LaTeX plugins secure. Look at his homepage for further details.

I have read it. It is better to restrict access to critical plugins in a consistent and understandable way than to require security to be provided by the plugins -- simply because that will never happen and because it is a waste of time if everyone needs to know any gory security detail of any plugin. One just needs to make sure that the content fed to security-critical plugins only comes from a trusted group of users. Why is that doomed to fail in a wiki?
No the plugin needs to be secure or you better don't install it. Probably use only plugins which comes from a trusted group of users and were you know they have spent time and discussed security. If no one cares on what could be a critical plugin who should know and who should restrict?

SSL support for the standalone server

I've created a patch to add TLSLite support to the standalone server. This provides a totally portable (complete Python implementatoin) secure Wiki. It may be slow, but in many cases it's good enough. The patch is at: MoinMoinPatch/StandaloneServerTLSLiteSupport.

The patch adds two config variables that must be specified in moin.py. moin.py must have the server's private key and CA certificate. The private key cannot be password protected (limitation of TLSLite without additional support libraries). The server forces ssl connections (redirects to ssl), it will not run in mixed mode.