The main point of this release was to split off all the channels and filters into there own modules for easier management and quicker development.

You can now keep track and find new releases from http://pear.cyberlot.net

If you can not use PEAR to download the release you should check out the latest branch from SVN.

I would like to thank Greg and his great work on the PEAR server which you can find releases for at http://pear.chiaraquartet.net/

I have looked at a lot of AJAX and DHTML implementations and everything I found either didn't fit my needs our was to expensive ( I don't mind paying for usefull products ). After trying a couple librarys yesterday I decided to try to roll my own and came up with the following

Sortable Demo

The interesting thing is I am in no way a java or DHTML expert, and what I came up with does pretty much everything I needed and is a lot less complicated and a lot cheaper then the a majority of what I looked at.

Each row is sortable, you can even configure the method used to sort, the rollover is added to each row, the paging tags at the bottom are auto generated. Even a minor template system so you can format the data after sorting, for maybe you want the data to be a link to somewhere. All in all it just works and is simple, Tie in a little AJAX or just a simple PHP script to output the data array and your good to go.

With this release a basic chat room is now possible although the flash client is yet to be worked on, thats the next step.

The API has stablized enough that basic docs are now provided through the use of PHPDoc.

http://www.sitepoint.com/article/take-command-ajax

A great article on AJAX overall however there choice of shell_exec and system commands as a example isn't really smart. Anyone testing there code could leave a possible huge gap in there server if they are not carefully.

The main issue I have is the way data validation is being done. You should never, never ever send any request command directly into shell_exec period no matter what checks you have done!

Another release, the whole channel concept was rewritten from the ground up with a more formal observer pattern that handles both channel and new filter input.

Channels are for specific interaction, for example a chat channel, or a game channel while filters can be used for various tasks. A good example would be a profanity filter.

Hopefully in the near future I can get the basic chat functionality completed so a example flash client can once again be provided with the source.

At first glance I had to applaud the thought behind the idea and that work that went into it but I had some nagging issues in the back of my head as I looked around there site, The main one being "How in the world will they keep it secure".

The fact that they let you manage, edit and do what ever to your php files on there servers is where the idea just hits a brick wall in my head. Let people download there pre-created sites in a package sure but hosting all these sites?

After working on CyberSS for a year and a half now, what started out as a simple socket server example and slowly expanded to a working chat server including being published in PHP|Arch has come to a new beginning.

CyberSS was not a chat server from the start, the modular code was added on as a second thought to have a working example and I quickly ran into problems so I decided to start over, http://www.FlashUnity.com is the beginning of that path.

I am in the middle of a complete rewrite of Cyber Socket Server from the ground up.

The original CyberSS was meant purely as a learning example of how sockets worked and how to connect them to other programs, in this case flash. In expanding that example it became a open source Flash XML and PHP based chatroom that never really went anyware. It works but well and fast but since my flash is limited it was never really a feature filled chatroom, just a barebones platform for people to learn from.

For more info on the old project
http://projects.cyberlot.net/trac/cyberss

To learn more about the new project read on.

In my previous entry you saw how a "tutorial" showed a nice insecure way of accessing content pages, What about a more secure way?

In my opinion when it comes to using includes of any type using a user inputted string directly should always be avoided. Think of it this way, even if you filter the string using regex to only allow alphanumeric characters what happens when there is a exploit in regex?

This may be a little paranoid but think about it, Any function that allows "system" access should be treated with an extra layer of resepect this being on of them.

I am not normally one to rain on someones parade. I really hate commenting on others work because no one is perfect and we all get things wrong from time to time.

Here I just have to make an exception http://www.developertutorials.com/tutorials/php/easy-site-navigation-php...

This is how NOT to write easy site navigation in a secure manner.