Posts Tagged development
Sorry about the lack of new posts!
Posted by admin in Developer updates, News and updates on January 31st, 2010
I apologize for the lack of posts lately. I have yet to post anymore tutorials on how to use some of SnowCMS’s tools, like how I did with the API class. But don’t worry, although I have not been that active posting here, I have been fairly busy working on SnowCMS.
I recently completed a new tool for SnowCMS, the Form class. The Form class allows you to create forms (if you didn’t notice) that can then be hooked into via the API and changed, without you needing to do any extra effort, you simply make the Form how you want to, and then display it. Right before the form is displayed (or processed), the API runs a hook which allows the modification of the form, from adding, changing and removing fields. In fact, currently the registration form uses this Form class, and the very first SnowCMS plugin hooks into the form and adds a CAPTCHA verification image. It’s very simple to do!
For the time being, I need to get some sleep (it is 12:15AM at the time of this post), but I hope to soon create a more in depth guide to the creation of forms using the Form class.
Cya soon!
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!
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.
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.