Keeping your credentials secure
Posted by admin in Developer updates on January 20th, 2010
One big goal of SnowCMS is providing a secure system, but of course, who wouldn’t want that? In order to keep that system secure, user credentials also need to be kept secure, because if someone gets a hold of that information, especially of a member who has powers, your site would likely become compromised.
So how do we keep your password secure? For starters, the password kept in the members database is salted with your username and then encrypted using SHA1. By salting your password, it helps prevent the use of rainbow tables (You know, those sites that have databases with plain text strings and their encrypted counterpart). Then there is logging in, when you submit your credentials through the log in form, your password gets salted with your supplied username, hashed using SHA1, then salted with a randomly generated string which is done by the server. Your plain text password is deleted before the form is sent to the server. Now, this only will occur if you have JavaScript enabled, of course. Once the hashed password is sent to the server, it takes out your members row, and salts (The last salt generated) the hashed password in the database and hashes it, then compares it to the one received from you. If they match, that means your password is correct.
Securing your password before being sent to the server might seem a bit overkill, but it can be very useful. As you never know, someone could be logging POST data, which would contain your log in credentials. All they would get would be your encrypted password which is salted with a randomly generated string. The only way they could ever use that password to log in to your account would be if the server were to generate the same random string, which is highly unlikely.
There are two ways that SnowCMS keeps your password from ever being seen by human eyes, but there is still one more. Cookies! No, not those kind, the Internet kind. With every page load, your browser sends the cookies to the server, where they can then be used to identify whether or not you are logged in. Instead of sending your password just with your username salting the password, there is also a randomly generated hash in the database that salts your password in the cookie… Just in case 
Not all people have access to SSL, which would stop such possible attacks, which is why we at SnowCMS have decided to use such tactics to protect not only the system itself from security issues, but also the people who use our system as well.
Just a reminder, the SnowCMS Dev Forum is now open to the public, if you are interested in having part in the development, or just like to see what is happening, you should come and join us.
Till next time, cya!
SnowCMS Dev Forum now open to the public!
Posted by admin in News and updates on December 28th, 2009
Hello everybody, I am happy to announce that the SnowCMS Dev Forum is now open to the public!
So if you are interested in getting involved (whether it be giving input, reporting issues, or whatever!) why not come check it out?
Merry Christmas!
Posted by admin in News and updates on December 25th, 2009
The SnowCMS Dev Team would like to wish everybody a Merry Christmas and a Happy New Year! Sadly, there is no SnowCMS release for the holidays 
I would have been very excited to be able to release a beta version of SnowCMS during the holidays, but unfortunately I have been very sick lately, and coding when your sick is no fun! But don’t worry, I am getting better and slowly adding to the codebase. Lately I have been working a lot on the API’s and tools which will come with SnowCMS such as the Members and Messages classes.
Till next time, cya!
It has been awhile
Posted by admin in Developer updates on December 6th, 2009
It has been a bit since I have talked about SnowCMS, so I thought I should make a post to keep things going.
In order to allow developers to see all of what goes on in SnowCMS in a more orderly fashion, such as API’s available, the SnowCMS SVN includes documentation which is compiled every now and again (by antimatter15, not me…), which is available here. We know that a system can be great, but that system isn’t useful if no one knows how to use what the system has to offer, so developers take advantage of what SnowCMS has to offer. Currently we have a few available classes and such to aid developers create plugins much faster, and without requiring plugins to have code that multiple plugins might end up having to include themselves, which is unnecessary. So I thought that I would, over the next week or more, make some posts about how to use the various API’s and classes available to future developers.
API
The name is pretty self explanatory, but as you can see, there are many available methods which can be used by plugins, and of course, this will no doubt be the most used by plugins.
Adding a hook
A plugin can add a hook via the $api, to modify the behavior of the system, or just do some action at the time of the hooks execution. Here is an example:
/* ... */
# Your function which will be called on later...
function my_hook(&$str)
{
$str = "I HOOKED YOU!";
}
# Register your hook with the API
# The first parameter contains the hooks name, the second is the callback, so either a function name
# or an array containing the object and the method to call, so: array($obj, 'method') would be like calling
# on $obj->method(); The third parameter is the importance of your hook over any other possibly registered
# callbacks. Defaults to 10, but the lower the number, the sooner that callback will be called upon. Last,
# but not least is the number of arguments your callback accepts.
$api->add_hook('the_hooks_name', 'my_hook', 10, 1);
/* ... */
# Now somewhere in SnowCMS's code, a hook is ran, and if you registered a callback on that hook,
# your callback, is, erm, called 
$text = "Hi...";
$api->run_hook('the_hooks_name', array(&$text));
echo $text;
Now once all that was ran, “Hi…” would not be seen on the screen, but “I HOOKED YOU!” would be because the function my_hook had $str be a reference parameter, and when run_hook was called, $text was defined as a reference as well, allowing any function that hooked into this hook to change what $text contained. Of course, just changing text won’t be the only thing available through hooks, but there will be a lot more, but that depends upon the hook itself. Right now there is a small list available at Google Code of currently available hooks in the system, but as time progresses, the list will grow 
Adding an action
When SnowCMS refers to an action, we mean an action in the URL. With the API, plugins can register actions to add some major, or possibly not so major, but still important, features to the system. Like say if there was a forum plugin and they wanted the forums index page to be accessible through index.php?action=forum, well, you can do that, and quite easily, I might add.
Adding that accessible page is done like this:
/* ... */
$api->add_action('forum', 'forum_index', 'location\of\the\forum_index.php');
/* ... */
Now when index.php?action=forum is accessed in a browser, the file “location\of\the\forum_index.php” is loaded and the function forum_index is called on. You can also leave the third parameter blank (the location of the function) and forum_index would just be called on. Through this method plugins can add pretty significant features to the system, like forums, pages, blogs, news, directories, or anything, really. Pretty slick, huh?
Adding a sub action
Along with adding an action, you can also add a sub action, the difference is that the action must implement the usage of sub actions. Such as the forum plugin (there isn’t really one, yet, I am just using it as an example ) it must use the API (which larger plugins really ought to, but don’t have to, use the API system to allow any other possible plugins to enhance the plugin itself…) to see if there are any sub actions which are registered (More on that later).
So now say you wanted to add a feature or something of the like to the forum plugin (index.php?action=forum) such as a statistics page. You would do this:
/* ... */
$api->add_subaction('forum', 'stats', 'stats_page', 'location\of\the\stats_page.php');
/* ... */
When you would access index.php?action=forum&sa=stats “location\of\the\stats_page.php” would be loaded and stats_page would be called upon, but of course, just as with add_action, the location of the function can be left empty.
Adding a group
Since we wanted to keep SnowCMS simple, we thought by default the system would only have 2 groups, an administrative group (administrator) and a member group (member, of course! But there is also a group called guest which you can’t assign yourself ). Why? Well, think about it. Most operating systems have 2 groups, administrators, which can really do everything, then there are members, which just plain get the privilege of using the computer So there are only those two groups. However, plugins are likely to add features which members shouldn’t be always allowed to use, nor should administrators be the only group allowed to use it either. So to make that work, plugins can register groups, which administrators can assign to members, which therefore elevate the abilities of that member.
First things first, a plugin needs to register the group, otherwise an administrator can’t assign (or at least, easily) the group to a member.
/* ... */
$api->add_group('forum_moderator', l('Forum Moderator'));
/* ... */
The first parameter is the groups identifier, which is the string stored inside the database, the second parameter is the human readable name of the group, in this case, Forum Moderator (I bet you are wondering what the l() function call is for, that is for language support, but more on that later ).
Now, when you want to see if the current member is allowed to perform the tasks restricted only to forum moderators, you would do a little something like this:
/* ... */
if($member->is_a(‘forum_moderator’))
{
/* They are a forum moderator, proceed */
}
else
{
/* They aren’t a forum moderator, yell at them! 
*/
}
/* … */
There you have it… And of course you don’t need to worry about the checking of administrator’s, if the member is an administrator, any call to the method is_a is automatically returned as true.
So there you have it… A insight on how to use SnowCMS’s API class, that is all for the time being, but come back soon and I will be posting about other tools available in the SnowCMS which developers will be able to take advantage of.
Member groups, plugin dependencies and language support
Posted by admin in News and updates on November 24th, 2009
It has been a few days since we have announced the death of SnowCMS v1.0, and the soon to begin development successor of SnowCMS v1.0, SnowCMS v2.0 (codenamed North Pole, my idea ). As stated, SnowCMS will be a pretty darn modular system, basically only including a member system, plugin system (plugins called flakes in the SnowCMS world) and a set of API’s. With these API’s developers will be able to add numerous features and enhancements to our system, in fact, the SnowCMS Development team will be creating modifications to extend the systems capabilities, but still allow users to enable and disable flakes they don’t want. Meaning SnowCMS technically speaking isn’t a Content Management System, it is whatever you want. You could just enable a forum flake, and it is a forum, enable pages, it is a simple CMS, enable a blog flake and it is a blog, and well, you get the idea…
Well, anyways, we have been busy planning the system before we dive into coding, some recent planning was about member groups, plugin dependencies and language support.
Member groups
We have been wondering whether or not we should allow users to add more member groups and change the permissions accordingly, but we also wondered about predefined groups, sort of like what WordPress does. With predefined groups it may be somewhat simpler to implement, but it is also somewhat easier on the users themselves as they don’t have a ton of member groups that they have to be like, what does this one do that the other doesn’t? and so on, but the con of such a system would be the fact that users wouldn’t be allowed as much control as possible.
After we all thought about what we should do regarding member groups, we decided to have predefined groups, however, the API would allow plugins to easily register member groups with the member system. The system by default will have two groups, Administrators and Members, Administrators being able to do whatever you can throw at them, but Members being, well, no where near as powerful. However, with the API plugins have the ability to register groups, that way they can have groups that can do more than what Members can, but still less than an Administrator, pretty much just elevating a Members permissions, slightly.
Plugin dependencies
Since most of the core system will only be a member system with a plugin system (along with some API’s), some plugins may actually enhance other plugins, so a plugin for a plugin, and in order to enable that ability, a plugin needs to know that the plugin(s) it depends upon, exist and are activated. We thought about just allowing the plugin to specify the name(s) the the plugin(s) it depends upon, but of course multiple plugins can have the same name, and what good would that do? Even if on the SnowCMS.com plugin site required that no plugin had the same name, that doesn’t mean there couldn’t be any other plugin out in the wild (or on another plugin site) that it depends upon. Tricky tricky, or at least confusing.
So antimatter15 came up with the idea of specifying the plugins address where information about the plugin can be found and downloaded as well. For example, say I (aldo) was the author of a plugin called Super Awesomeness (So the URL friendly version would be super-awesomeness), and if another plugin depend upon Super Awesomeness v1, it would specify snowcms.com/p/aldo/super-awesomeness/1.0. The plugin system would check to see if that plugin is already on the site, and activated when activating the plugin which depends on it. If the plugin isn’t already on the site, it would prompt you saying that the following plugins are required for this plugin to operate, do you want to download and activate them? (Listing them, of course). Then those dependencies would be met, and the plugin could be activated and work, as expected. The cool thing about this is that the dependency names specify the whole domain of where the plugin resides, allowing third-parties to manage their own plugins and such. (You will also be able to specify an update URL for that plugin, which periodically it goes to that URL to see if there is a newer version, if so, it tells the user that there is an update available. This will allow people who maybe sell plugins to others, but provide the purchasers with updates… )
Language support
With SnowCMS v1.0, language support was done through variables, such as $l['go'] would contain Go, and $l['confirmation'] would be Are you sure? and so on. That was slow and tedious work, having to update a language file every time you wanted something to be written out, and having to see if something like that was already in a variable elsewhere, so this time, we are doing it slightly different.
We have decided to create a function called l (that is a lowercase L by the way ), the parameter being the text you want to have output in English. For example:
l('Hello there!');
Now if your systems language was set as English, that string would simply be returned, however, if your systems language was in another language, a language file would be loaded and the correct language string would be returned.
Now, on the SnowCMS site, there will be a portion of which where people can contribute to translations. By default, Google Translator will be used to translate English into whatever language, but we all know that those translations are never 100% correct, so people will be able to modify those accordingly. Every so often the system will check to see if there is a newer version of translations, and download them (These translations will be a plugin, actually ) like say if another string was added (There will always be newer plugins and newer plugin updates which may have a string which is not yet translated, which is reported to the translation site) and what not.
Well, that is about it for now, until next time, cya!
SnowCMS v1.0 publicly available, but…
Posted by admin in Developer updates, News and updates on November 20th, 2009
On behalf of the SnowCMS team, I would like to announce that SnowCMS v1.0, which the SnowCMS Dev Team has worked on for some time, is now publicly available at the SnowCMS Google Code repository. However, there is a slight catch…
As of today, SnowCMS v1.0 is dead, but that doesn’t mean that the SnowCMS project is dead. We, the SnowCMS Dev team, have started to plan a newer version of SnowCMS, which will be SnowCMS v2.0, and this time the system will be bare bones, with only the basics, such as member management and a plug-in system, much like that of WordPress.
Now don’t think that the system with ship with only member management, that is merely the only feature which will be enabled by default, plug-ins made by the SnowCMS Dev team to extend the bare boned functionality of the system using the hooks and API’s provided with SnowCMS. We are looking forward to creating an extremely modular system, and as time passes, you should start to see code appear in the repository and more information posted here.
You are probably thinking why has this happened a second time? First there was SnowCMS v0.7 and now SnowCMS v1.0… Why did this occur? The problem was that we tried to provide a system with to many features and such at one time and after awhile, we just became overwhelmed with what we had to do, so we stopped, and we decided to once again start new, light, and well planned.
Got questions? We might have answers…
Posted by admin in News and updates on July 31st, 2009
I always like to keep people who are interested in SnowCMS aware of what is going on, but sometimes I am not quite sure what it is I should talk about in these posts. Since right now these posts are really the only connection we have to the community.
So if you have a question about the development of SnowCMS, simply post a comment on this post, and I will try to answer it in a later post as best as I can. Thanks!
Lots of pondering going on
Posted by admin in Developer updates on July 29th, 2009
Right now Myles and I are pondering about quite a few things to put into SnowCMS.
Mod system
Of course SnowCMS will have a modification system, and the dev team and I were thinking about how to do it. Some systems have a sort of API system, where basically every so often, the system will call on some kind of hooks are integrated for developers to latch on to. But there is not much power. Sure it would be simple for use to make, and then updating SnowCMS powered sites would be a snap, we don’t want to take the easy way out
Other systems allow you to modify all the files themselves. It can be a little more complicated, but it also poses a threat to users if they were to install malicious modifications. Probably pretty unlikely, but hey! It can happen…
Another way is super easy. Not having one at all. Of course, we wouldn’t do that. We have come to a unanimous decision to have file based editing for the modification system. Oh, and did I mention modifications are referred to as ‘flakes’?
Mod security
As I mentioned about allowing people to modify the sources of the system can be dangerous. So how are we as developers going to combat that?
Pretty simple, well, at least simple in concept. What will happen is people will be able to submit modifications to our site (Eventually we will have a modifications database, of course!) and once the team has reviewed it (Either developers, or maybe a modification team) and approved the modification to be done well and doesn’t do anything bad, the file will have its hash taken (SHA-1, most likely) and stored in a publically accessible way (In a database and can have the data retrieved). Now once the modification is uploaded to your site, and once your about to install it, your system will hash the file and send it off to SnowCMS.com. We (well, the server…) will then take that hash and check to see if it exists and is approved in our database. If it is, you will see a message saying the modification is safe and has been approved by the SnowCMS team.
A pretty good idea. Because if that modification which you uploaded to your site was changed in any way, it won’t be in our database. Simple, but darn effective =P.
Updating
Since SnowCMS will feature a modification (flake) system, updating will be pretty straight forward. Once SnowCMS goes gold, whenever an update is out (Like 1.0.1) we will have those updates put into a flake package. That way even when you have modifications installed, you should be able to update pretty easily with little to no errors. But of course, in the beta and RC stage, you will not be able to update via this system due to the major amount of code changes that will occur. Sorry!
BBCode
Like I talked about in previous posts, I certainly hope by either public beta release or when 1.0 goes gold, we will have the new BBCode parser complete. Still working on it.
Well, a lot of information about SnowCMS v1.0. Until next time, see ya! XD.
DNS maintenance July 26th
Posted by admin in News and updates on July 21st, 2009
This Sunday (July 26th) at 12AM PDT the SnowCMS domain will be transfered to a new DNS setup. Right now all DNS for SnowCMS.com is hosted on EditDNS’s old system so I will be transferring it to the new one.
It shouldn’t really affect many people, but just thought you ought to know
Update – DNS maintenance was successfully completed at said time.
Topic posting complete
Posted by admin in News and updates on July 16th, 2009
Today I worked quite a bit, and I finally got topic posting completed and working without errors Still no replying or editing done yet, but I am working on it!
And about the BBCode, I still haven’t completely finished it, but it is almost there XD.