BoltWire is a content management system developed by Dan Vis.

Welcome Tour
Mailing List

Popular Posts

Version 5.11 Released
May 26, 2016

Big Changes Coming Soon...
April 28, 2016

Catching Up
April 6, 2016

Other Sites

Here's some other sites by Dan Vis:

Alexa Echoes
Join my adventures developing for Amazons exciting new voice platform.

Firefly Spot
Personal rambling about new gadgets, technology news, and space travel.

FAST Missions
My ministry hub, with news and updates about our online school.

You can follow him at www.danvis.info.


Documentation > Concepts > Security

With something as flexible and powerful as BoltWire, security is important. BoltWire offers several layers of security, but here are the most important ones:

Group Permissions

BoltWire comes with a number of member groups built in--such as admin, editor, member, guest, but you can create as many different groups as desired. For a list of the default groups and their characteristics, see the memberships command. See this tutorial for information on how to create groups, and add or drop members.

Permissions for various actions on your site can easily be set to specific groups, or even specific members. When you first setup your site, reasonable permissions are assigned, but they can be modified however you desire. These are controlled by site auth pages. BoltWire comes with several auth pages built in:

See the pages already on your system for examples of the syntax you should use on these pages. If you have custom groups, you can assign permissions to those groups using syntax like @chess. You can also add specific users to any line--by simply adding their id.

Note: BoltWire's authorization system is quite flexible. You can create as many additional site auth pages as you like, and use them to control how your site works. Developers can also tap into it by developing new auth pages for specific plugins.

Authorization Keys

There are many situations where you want an individual to write to a page, without giving them full edit permissions, such as a comment box in a forum for example. To do this, simply create a form and add a command like this:

[command authkey comment]

Then add @key_comment to the write authorization page for the pages you wish to authorize the comment box. Members will not be able to edit pages, create new pages or do any other write functions--except make comments using your specially enabled comment form.

If you only want logged in users to post comments, wrap the entire comment form in [if login] and [if]. Better still, do: [if login]Comment Form...[else]Login to Comment...[if]

Dynamic Authkeys

Here's another example. Suppose you wanted to let users create their own note pages (like note.userid, note,userid.one, note.userid.two), and edit them. You can do this by assigning authkeys dynamically.

This approach will work fine:

[command authkey mynotes if='equal {p2} {id}']

Then add @key_mynotes to your notes* hierarchy. The authorization will only be granted if they are on page note.userid or some child page. In many cases it will be preferable to wrap the entire form in a conditional like: [if equal {p2} {id}]My form...[if] so the form does not even appear unless they are authorized to use it.

I can of course use any conditional I like. Suppose I only wanted to allow members who lived in Alaska to post or view a page. Set the conditional to: [if equal Alaska {~state}]...[if]. This gives you virtually unlimited flexibility

Special Page Groups

BoltWire has another trick when it comes to page names/groups. When it loads the site auth page it automatically substitutes {id} with the users id. So if you set site.auth.write to:

notes*: @editor
notes.{id}: @member
notes.{id}.*: @member

BoltWire will allow members to edit their notes page, and any child pages. But not pages in another members note hierarchy. I used two lines to do this so 'bob' couldn't edit pages owned by 'bobby'.

Note you can use the same approach to make pages private. Simply add the lines above to the view auth page.

Conditional Permissions

Another approach to control view permissions (or any other auth type) is the use of conditionals. Notice for example the following code:

[if ! ingroup chess]<(forward error.page)>[if]

This will check to see if a person is in a specific group, and if not, forward them to a member page. This can be put in a footer or header and it could control access for a whole group of pages.

Suppose your site had multiple clubs, like club.chess, club.backgammon, club.checkers. And each group had it's own pages. You could put this in club.footers to control access to all clubs at once:

[if ! ingroup {p2}]<(forward error.page)>[if]

Note: This approach would not block pages from being included into another page (using the include function), because technically the user still has view permissions. He is only being diverted away.

Edit Protections

To prevent users from entering harmful things into your site, the following values are escaped depending on the identity of the individual:

While it is easy to change view and write permissions, the above edit protections are hardcoded into BoltWire and cannot be modified without changing the core code. Therefore, it is recommended you assign individuals to the right groups depending on the kind of editing you want them able to do, and then modify their view and write permissions accordingly.

The default permissions set in site.auth.view and site.auth.write generally give admins unlimited access to the site, give editors access to most functions required for site maintenance, members can write to non system pages and use some actions, and guests can view non system pages. Study the security settings carefully before changing them. You may also wish to review the tutorial on page hierarchies.

Note: You can change group membership directly in config.php or a plugin by modifying the $BOLTgroups variable.

To leave a comment, please login using your Facebook account: