Welcome

BoltWire is a content management system developed by Dan Vis.

It's innovative architecture combined with best in class forms processing gives you complete control over every aspect of how your site works.

BoltWire doesn't just let you change content--it lets you change the engine itself right through your browser!


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.

Changing Titles

Posted June 15, 2015
Share this post:


Got asked a simple question today. Resulted in a major rambling about permissions.

The question involved a suggestion to let users modify their own titles in the forum. Here's the story if you are interested--gives a bit of insight into how BoltWire has developed over the years.

Part I: The bug fix

When I first looked into it, I discovered a user could simply add &action=title to the url when logged in, and change it. But then I thought--why, since general users don't have write permission. So I logged out and tried it. And again--I could change it. Even worse! But again, why?

Some time back I discovered this security hole and fixed it. As long as you don't set dataAuth: false in site.config, you are required to have write permission to write to a data var.

So I checked site.config--and I didn't see the line there. But it definitely was still happening. It was almost as if BoltWire was reading config values from the wrong page somehow. To make matters worse, the more I tinkered the more I noticed problems with the site.folders page as well--resulting in me temporarily breaking most of the links in the BoltWire site.

To make a long story short--I discovered a bug with the new sitePages var I added in 5.02 (only affects those using it). Once fixed the title action became locked down as it's supposed to be, and everything else returned to normal.

Long story to get to the point, that changing titles is now successfully turned off on the BoltWire forum...

Part II: Possible solutions

To enable title editing in the forums would not be hard if you wanted it on your forum. Simple go to action.title and copy it to action.forum.title. This new title action will take precedence over the default title action on any forum page (all action pages are fully hierarchical like this). Now, modify the action by adding this line to it just before the savedata command to add an authkey:

[command authkey forum]

If you wanted to only allow this for logged in users, and only on actual forum posts (not other pages in the forum) you could make it a bit smarter:

[command authkey forum if='login && number {p3}']

This only sets the authkey if, well, logged in and the page ends with a timestamp (singling out only the user generated forum posts). It also assumes you have authorized that key in the forum on your site.auth.write page. Note you could easily set it to check if the user is the author of the post in the same way.

Part III: More Possibilities

It is funny this came up today, because I woke up thinking about something related. It occurred to me there was a need for (even) more flexible auth control of action pages. That is, I can limit access to the title action page to certain users on site.auth.view, and its ability to actually make changes to titles on site.auth.write, but there's no way to easily give different groups of users different access to different pages!

So for example, I want blog editors to be able to edit blog post titles, but not general users. However I might want general members to edit forum post titles. And some pages I might want to limit the title action to only admins, or other specific groups. At present I can only block or allow access to the action.title page sitewide.

In my mind, I thought, what about allowing admins to create auth pages for specific actions? For example I could create an optional site.auth.action_title page where I could create entries like this:

*: @editor
forum*: @member
site*: @admin

It would only take one line or two in the BOLTpageShow function to implement this feature. No disruption to existing sites. No hit on performance. My mouse hovered over the code...

I couldn't resist. Added the new line of code. Tried it out. Worked the first time. (That part was a bit unusual!)

Turned out kind of cool--with the bonus that you get the blocked screen rather than showing the title action but failing to save the change because there is no write permission. Which I also discovered. Just giving access to the page doesn't mean you can use it without also giving the user write permissions.

I weighed the pro's and con's. I really despise feature creep. I see perfection more in how much we can cut out than how much we can add. I've stuck to the 100k limit for a long time and plan to continue doing so. Bragging rights.

Well, finally at last, I decided to keep the new feature. Adds some pretty cool flexibility. Just a tiny bit of code--and won't affect performance at all. And no disruption to existing sites. Hey, what's not to love?

Posted by Dan Vis on 06/15/15
While I'm at it, I guess I should point out the whole point of this blog post: BoltWire very likely has the most flexible permissions system of any comparable system out there. And it just got even more flexible!
To leave a comment, please login using your Facebook account:

About the Author

Dan Vis is intrigued with tomorrow. He is a speaker, author, and developer. Here, he writes about gadgets, online learning, space travel, and the future in general.

He is the creator of BoltWire, a paradigm-busting CMS. He suspects Alexa may be a turning point in technology and blogs about it at AlexaEchoes. He stays busy at FAST Misions, where he operates an online school with students from around the world.

You can learn more here: www.danvis.info.