I have a secret project that I am working on at the moment. One of the features for this project, is the entry of user data, that will then be displayed to the general public. I wanted to allow the user to format this data so that lists (ordered and unordered) could be used. Bold, italic and underline text would also be nice.

To allow this entry, I looked for a WYSIWYG editor. I settled on FCKeditor, and configured it to show up on my two <textarea> boxes on the entry form. I specified a custom toolbar:


FCKConfig.ToolbarSets["custom_toolbar"] = [
['Bold','Underline','Italic','-','OrderedList','UnorderedList'],
['SpellCheck','Undo','Redo']
] ;


This would allow the entry I wanted, while disallowing viewing of the HTML source and other features I did not want. On my first test, I wanted to see if a simple security risk would be allowed, the use of a hidden <iframe> to load some external content. I went into my text area input box, and simply added:

<iframe src=”http://www.google.com></iframe>

I already have the POST input being filtered through input filters:

filter_input(INPUT_POST, 'input_value', FILTER_SANITIZE_STRING);

On this test, when I viewed the output everything seemed fine. The < tags were being filtered as &lt; for entry into the DB. The output HTML source code seemed to verify this, and the output actually showed the iframe code, rather than the iframe itself. All seemed ok…

Later I came back, and wanted to make sure everything was ok. I added some size attributes to the iframe entry, such as width. This time, I was shocked when I viewed the HTML output and was looking at a Google window. Obviously my assumption that the input and output was secured was wrong, and is a good lesson to not be lazy.

At first, my incorrect solution was to use strip_tags(); and then decode on output display, to simply get rid of all other HTML coding. Yet this fails for one large reason, tag attributes. I had allowed some tags such as <strong>, <em>, etc. Yet attributes such as ‘onload’ would still slip through. Rather than use strip_tags with disallowed attributes listed in an array (such examples are given on the PHP strip_tags page, in comments if you wish to see them), I chose to use HTML Purifier. I really like this library and does exactly what I need it to do.

Overall, this is why good testing and thinking about security from the start are required.

InfoWorld had a piece today about scripting languages, and the future they may hold. While not offering any solid indication on which will have the biggest future in store, it does mention how they may all in fact be worthwhile to learn and program with.

Most programmers who’ve been around long enough to survive the rise and fall of programming languages such as Cobol and Fortran recognize that the problem isn’t a life-or-death matter. There won’t be one winner, and backing the wrong horse won’t be fatal. These stable old hands point out that Cobol continues to run strong. At this writing, more than 1 percent of the listings on Dice.com include Cobol. By comparison, JavaScript draws a bit more than 7 percent!

Yet learning and investing time into a language that may lack support over the years is certainly a concern. Not only to make yourself marketable for a job, but future proofing as much as you can your knowledge.

The Tiobe Index gives some insight into current popularity, and some trend info for the same month a year ago. Yet that still does not offer the crystal ball…

For October, the scripting languages cited in the article rank as:

1. PHP – #5 – 8.612%
2. Python – #6 – 4.565%
3. Perl – #7 – 4.419%
4. Ruby – #10 – 2.869%
5. Javascript – #11 – 2.670%

Stanford is offering free access to 10 Engineering course material. In a program called Stanford Engineering Everywhere, you can view the course syllabus, download course material, take tests, and more.

Courses being offered (with more to come at a later time if they go well):

• Programming Methodology
• Programming Abstractions
• Programming Paradigms
• Introduction to Robotics
• Natural Language Processing
• Machine Learning
• The Fourier Transform and its Applications
• Introduction to Linear Dynamical Systems
• Convex Optimization I
• Convex Optimization II

Very very interesting stuff. Once I get a break in my own schooling, I will be going over the material myself. The programming classes will tie in perfectly with some of my own, and the others are just plain interesting. I mean, who doesnt love Fourier Transforms? Seti@Home anyone?  ;-)

Forget where I saw this, but funny stuff. To determine if your code is good or bad…

The CSS rendering differences between IE and Firefox can be frustrating and irritating. The majority of issues I have come across between the two arise when using nested DIV’s, and the positioning of these DIV’s.

One recent example, was setting up a menu bar. Perhaps in bad form, I used the following:

<div id=”Parent”>
<div id=”Child”>
Content
</div>
</div>

#Parent {
width:800px;
margin-left:auto;
margin-right:auto;
}

#Child {
width:790px;
margin-left:5px;
}

Now, the Child DIV was a smaller width due to some background images and lining up content to this background. I was attempting to use a left margin to set the position of Child within Parent, and the width automatically setting the right margin due to the value defined. All would work in Firefox when I was building the page. Yet after I would check IE to verify all was kosher… I would see the problems. IE was making the left margin appear differently than Firefox. To make matters worse, the right margin was also coming out differently.

So if I would change the margin-left value to be higher (as IE was showing the DIV further to the left than Firefox), Firefox would then show whitespace between the margin I wanted and the DIV container Child.

Changing DOC TYPE to strict did not help. So instead, I used this.

#Child {
margin-left:7px;
margin-right:8px;
}

The width was being defaulted to 100% inherit value, and the margins being declared on both sides. That worked. So… do not define the width value if you are having similar issues.

I am currently developing a RSS Feed in PHP. The project started because I am tired of having my feed reader at work, and then another on my laptop, and another at home. Leading to each computer not remember which story was read, each having different feeds, and so on.

With that in mind, I set out to create a feed reader that would do everything I needed it to do, and I was thinking of seeing how others on the web liked it.

Yet as I go over to Google Reader, it looks like I would be in a hopeless battle. The Google Reader is a nice piece of work. Does most things that I could want, as I am sure others would agree. So… Guess I will still work on mine just to see where it goes and what I can accomplish. Yet it may never see the light of day outside my own password protected domain it currently resides in.