HTML5 Video plugin for CKEditor

You might have heard a lot of people talking about the new features of HTML5, and one that has brought a lot of interest is the <video> element that some people think that will avoid the use of Flash once and for all (at least Steve Jobs thinks so).

Personally I don't think that it will be so easy to dismiss a whole environment like Flash just because videos now can be played without external plugins, leaving aside the fight of h264 vs WebM (or as is now: Apple & MS vs the rest of the web), Flash has a lot of features that aren't easy to replace, the most basic one, the fact that you deploy a single swf file, vs having to provide several javascript and images just to perform anything basic with javascript. And as soon as you want to use some effects, you might end up with something huge and in fact as slow as the dreaded flash files.

But back to the topic, HTML5 video and CKEditor. What about that?

Ok, here we go, this is a plugin sponsored by DM Logic that makes using the <video> element as easy as an old <img>, you can insert, edit, use the context menu, etc... the dialog allows to specify the poster image, the dimensions (they are automatically adjusted according to the preview) and two source files, so that both the browsers that use the WebM format (Chrome, Firefox and Opera) and the ones that support only h264 (IE9 and Safari) can view your videos. Here's a short video showing how it works.

Download it here.

Updates:

v.1.3 26/08/12: Fixed problems with IE9, wrap the video in a <div> to avoid the problems with <p>. It's compatible with both CKEditor 3 and CKEditor 4

Demo

This is an editor. insert a video (I still haven't enabled the file browser for this demo)

 

 

Background image plugin for CKEditor

People enjoy colorful pages, background graphics and everything that can make their pages show their good taste, that's why some of them haver requested such feature for FCKeditor and CKEditor.

It's not clear if it might get directly supported in the core but here's a plugin for CKEditor to include a "Background image" field (with a button to launch the server browser) in the Table and Cell properties dialogs.

You can download the plugin here, the zip includes an install doc explaining how to use it, just extract the zip under the plugins folder for CKEditor and add "backgrounds" to the list of extra plugins.

Thank you to Igenti, Inc. for sponsoring the development of the plugin.

Avoiding extra request for the translation of a CKEditor plugin

When you write a plugin for CKEditor, it's almost for sure that it will include some text, it can be the tooltip for the toolbar button, a context menu entry or some change to one dialog, and you can leave that string hardcoded in your language, but it's usually better to use the localization features of CKEditor so it's easy for users in other countries to use your plugin, as well as allowing to easily change the text to fit better in a different environment.

As you might know this is achieved by setting a "lang" property in your plugin that it's an array with the list of language codes that your plugin provides:

 lang : [ 'en', 'es' ],

That entry tells CKEditor to load the file with the translation from the lang file of your plugin (lang/en.js or lang/es.js), and it's a pity that with all the current efforts about improving performance, due to the desire to provide the translation your editor might load slightly worse as it gets that extra file.

But there's an easy workaround, you can put the localization in the plugin.js file itself, so that when it checks what does it needs to load for this plugin, it can see that the translations are ready and so it skips for the next item.

Now each translation is just a line in the plugin and it doesn't require an extra request to the server:

CKEDITOR.plugins.setLang( 'backgrounds', 'en', { backgrounds : { label : 'Background image'} } );
CKEDITOR.plugins.setLang( 'backgrounds', 'es', { backgrounds : { label : 'Imagen de fondo'} } );

 

Security attack from IP 92.243.90.103

I've noticed recently that the IP 92.243.90.103 is testing several servers, requesting for files related to FCKeditor and then checking for the availability of the connectors to perform operations on the server (usually I think that it's more common requests related to tinymce filemanager, but it doesn't really matter too much).

I don't think that the requests are related to an unknown problem with the server connectors in FCKeditor as it seems to search both the asp and aspx versions (maybe it acts depending on the server software), but there are a few points that everybody should remember in order to avoid problems.

As every other time that I've written about this issues, let me remember you that I'm not a security expert and these are just some basic guidelines, the basis is that you should try to create an onion around the security of your server, different layers so that an attacker has to go through all of them, and hopefully he should be stopped at the very first steps.

Keep only the needed files

Whenever you use a third party software (or even your own software), don't upload to the server everything that comes in the shipped distribution. You won't need at the server source files, samples, documentation, or integration files for other server languages.

By removing those extra files you are avoiding a larger vulnerable surface and you can focus on the important files.

Security by obscurity can be useful

Yes, security by obscurity isn't really secure, but this kind of automated attacks that just search any number of domains for some files at specific locations like "/FCKeditor/editor/filemanager/connectors/aspx/connector.aspx?Command=GetFoldersAndFiles&Type=File&CurrentFolder=/" can be avoided if you place this 3rd party components in a non-standard location, so something as easy as putting the FCKeditor in another subfolder can avoid that an automated attack finds your files.

It's also important that the files that the users upload to your server with scripts like the FCKeditor server upload, don't end up in a folder that gives any hint about how they have been placed there, if your files are under /scripts/CKFinder/userfiles I'll know that you are using CKFinder somewhere in your server and more important, you are stating the path for CKFinder so you are weakening a little the security that you got in the first place by using /scripts/CKFinder instead of just /CKFinder

Expose the upload script only to users that can upload files

If a user doesn't have permissions to upload anything, then he shouldn't be able to see any hint about what are you using to manage the files in your server.

Secure the upload folder

The folder where the users are able to upload files shouldn't have permissions to execute any script, so even if they are able to upload a script, it won't do anything. Using the IIS control panel or .htaccess files in Apache it's easy to perform this task.

Keep your code updated

This can be a pain, but you once you start using a script at your server, you should check from that moment any new release about that project, paying special attention to warnings about security problems in new releases. I think that every project has some kind of RSS feed, so it shouldn't really be that hard to at least notice the new versions.

Enable file management wisely

In FCKeditor and CKFinder the server connectors include a config file where you can adjust some parameters (location of uploaded files, allowed or disallowed extensions, types of files, etc...) but the most important one is the ability to state if the script is enabled or disabled.

By default the server connectors are disabled in FCKeditor and CKFinder as that's the safe default, but people the complain that when they try to use them they get a message stating that the connector is disabled. Of course, that kind of people are showing that they didn't bother to read the minimum about how to configure these scripts, so they might end up using other ones that are enabled by default and they won't ever notice that now everyone can manage the files of their servers.

The correct step is to use the login credentials of your CMS to enable the file management only for the correct users, you don't really want an anonymous user being able to upload a file to your server.

Finally: be careful

As you can see, I'm not revealing anything extraordinary, these are just some basic rules that can provide some basic protection, but there are more that you should be aware of and that's part of the task of managing a web server.

When you pick a file manager for your server, don't think only about a few buck that you can save by using a free manager instead of a paid one, check how the security is implemented in each one, if an attacker is able to get control of your server you can lose many times that money trying to getting it back to normality.

 

Public release of new Google Maps for CKEditor might finally see the light of day

For quite some time I've got almost ready a port of the Google Maps plugin for FCKeditor to the latest version of each API: Google Maps 3 and CKEditor 3, but there was a major problem that I wasn't happy about and that was the lack in GMaps 3 of the ability to create and edit polylines and areas.

I could have go ahead and state that it's finished without such feature, but that wouldn't be honest.

Or I could have worked out my own implementation, but I already created such code in the old times and I wouldn't like to do it again because I can't spend enough time polishing any issues and making sure that the code works correctly and that it's correctly optimized.

So I waited and waited...

And finally, yes, today they have stated that they plan to release it in the first quarter.

With this light at the end of the tunnel I'll try to verify that everything else keeps working as I left it some months ago and I'll be very happy to state that it's finally released even if there are some other missing features from v2.

Christmas present: WriteArea 1.0 is available

Last night, Jorge Villalobos as Mozilla reviewer approved the 1.0 version of Write Area as an update, so now you should start getting update notifications for this version.

What do you get with Write Area 1.0?

With Write Area you can use the best WYSIWYG web editor inside your Firefox: in any site that allows to input HTML, either with a textarea or even from other not-so capable editors, you can launch Write Area using the context menu and that way you'll get full editing capabilities.

This version has been adjusted to avoid the existing problems with Firefox 4, so the upgrade of Firefox should not cause you any trouble. Some other details have been improved like focusing existing instances.

The internal editor core has been changed from the old FCKeditor 2.6 to the latest CKEditor 3.5, so future upgrades should come out sooner now that the used editor is again one under very active development. Nevertheless, updates in an extension requires review by a AMO editor, so instead of releasing an upgrade with every CKEditor release I might publish a "beta channel" version for minor updates and a full one where there's a new milestone or some important bugs fixed.

Besides that, you can keep using the internal Firefox spellchecker in a normal installation of CKEditor if you install the Gecko SpellChecker plugin.

Go ahead, click and install this extension.

(another post powered by Write Area)

Little test of Firefox 4 beta 3 for mobile

As Mozilla has just released Firefox 4 beta for mobile, and due to a talk this morning with Garry about editing in mobile I wanted to check how does it rate just in a quick test of contentEditable vs the default webkit-based browser.

The basic test at the previous post is enough for the initial checks and it doesn't require anything special, anyone can easily test if his browser includes the basic functionality expected in a modern browser.

Here's a testing area again:

Type here.., a link (it's part of the content, so it shouldn't be active)

First test: I click on the div and a caret shows up. Firefox 1, Webkit 0 (nothing signals that the editable zone has focus)

Second test: scrolling with the trackball moves the caret. Firefox 2, Webkit 0 (it scrolls the screen)

Third one: clicking on the link doesn't tries to open it. Firefox 3, Webkit 0 (it opens the linked Google page)

Fourth: The keyboard opens automatically when the div is focused. Firefox 4, Webkit 0 (You must open it by long pressing the Menu key)

Fifth: Typing (default keyboard) is slooow, very very slow. Firefox 4, Webkit 1 (in this page it works as fast as any other input field)

Sixth: Typing with Swiftkey, it tries to edit the contents, it's almost impossible to use it. 8pen seems to behave a little better. It seems that the Android browser tells the keyboard to send only single characters or to ignore autocomplete, I don't know how to explain it, but for this situation I think that using the Webkit method works better. Firefox 4, Webkit 2

Seventh: tweaking the CKEditor env.js file to allow the Android browser, we can test it in the full environment. The context menu opens/remains open at the 0x0 of the content, trying to type anything is almost impossible, the editor gets the focus, the keyboard opens and then it's closed automatically. Firefox 4, Webkit 3. The context menu doesn't show up and once the keyboard is forced it remains there. This could be something that can be tweaked in CKEditor, as the simple test doesn't behaves so badly.

Conclusion:

None of them are usable :-(

Maybe Firefox could be much better if it was able to select/configure the way that the keyboard opens, and then we should try to understand why it behaves that way in the full editor. Besides that, Firefox is still missing other features (the zoom function seems much worse than webkit) so we just need to be sure to fill a ticket with Firefox so they might fix it in the future.

Edit 1: I've filed bug 621438 for the Firefox problems with the keyboard.