Security
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 four default member groups, but can be set up to have as many groups as desired. Permissions for various actions on your wiki can easily be set to specific groups, or even specific members. The default groups include:- @guest -- any visitor to your site that has not yet logged in
- @member -- a registered member who has authenticated their identity. All members have guest permissions.
- @editor -- a member with authorizations to edit most parts of the wiki, and create forms. All editors have member permissions.
- @admin -- a member with the ability to edit things like skins, css, create action pages, etc. All admins have editor permissions.
When you first setup your wiki, reasonable permissions are assigned to these four groups -- but they can be modified however you desire.
Note: BOLTadmins are members designated by a special $BOLTadmin variable in your index.php file, with unlimited authority in your wiki. If you define a BOLTadmin identity in your index.php file, you should be sure to password protect that account immediately. To enable multiple BOLTadmin accounts, just enter a CSV list of member id's.
Adding Groups
To create custom groups, simply create pages like group.chessclub and group.friends. Then put lists of member id's on these pages (one to a line). Individuals will be granted permissions for that group the next time they login. For more information about how to setup custom membership groups, including snippets for creating self-registering groups see the Membership tutorial.
Basic Authorization Pages
BoltWire comes with several authorization types view, write , data & info pre-installed. Its authorization system however is quite flexible, for designed for easy extensibility and use by developers.- site.auth.view shows a list of pages and the users and groups authorized to view them. It is also checked before allowing action pages, or retrieving data variables from a page. To block actions, simply limit who can view the corresponding action page.
- site.auth.write shows a list of pages and the users and groups authorized to write to them. It is checked by any command able to modify page content.
- site.auth.data shows a list of fields and which users/groups can have read access to that data. It does not apply to info vars.*
- site.auth.info shows a list of pages that will allow writing by the info command/function. By default, this is only allowed on "info pages". Furthermore, a user must have view permissions to retrieve info.
See the pages installed 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 @chessclub or @friends.
* Note, if data is stored on a users own login page, they are considered temporary members of the @owner group, when checking for read authorizations. By default, passwords are only visible to admins (even though they are encrypted), and emails are visible to editors and owners.
Other Authorization Pages
You can gain even more control of your site by creating additional site.auth pages. These checks are built into the BoltWire system, but do not go into affect until a page is created. Be sure you understand how these pages work before creating them.- site.auth.commands shows a list of pages, and which commands are allowed on each.
- site.auth.functions shows a list of pages, and which functions are allowed on each.
- site.auth.files shows a list of files (images, or downloads) and which users/groups can access them.
- site.auth.uploads shows a list of pages, and which users can upload files from them.
- site.auth.email shows a list of pages, and which users can send mail from them.
If you are a plugin developer, it is easy to tap into BoltWire's authorization system, and create additional auth pages as desired. You may wish to study the BoltWire code for examples.
Authorization Keys
There are many situations where you may want an individual to write to a page, without giving them full edit permissions, such as a comment box for example. Simply create a form with a field like:
<code> [session authkey comment] </code>Then add @key_comment to the write authorization page for the users and pages, where you wish to authorize the comment box.
Note: There are many other ways to generate dynamic group memberships in a config file for even more flexible authorization controls. See the Fancy Auth and Virtual Wiki solution pages for two examples.
Edit Protections
To prevent users from entering harmful things into your wiki, and yet keep it as flexible as possible, the following values are escaped depending on the identity of the individual:
- The < and $ symbols are escaped unless the user is an editor or admin, and they are editing a page in the code group. Code pages are generally used for skins, styles, js, etc.
- Similarly, the [form] markup is escaped if the user is not an admin or editor, so they cannot access the BOLT forms processor. It displays "[form]" in the wiki page.
- The data delimiter pattern (~data~) is also escaped for all users to prevent individuals from maliciously or accidentally entering data values directly into a page. Note, it is possible to put info variables on a page.
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 wiki, give editors access to most functions required for site maintenance, members can write to non system pages, and guest can view non system pages. Study the security settings carefully before changing them. You may also wish to review the Hierarchical Groups.
