2011/02/06

Creating extensions for each browser

These last days I've tried to create a similar extension for each browser, and this is a little recap of the first differences among them. A page with a full list of differences can be found in the State of the Add-on Developer Union

Firefox

In Firefox there are two options:

  1. Create the extension using the "classic" way that goes back to the very beginning and provides full access to anything in Firefox, you can customize it in any way that you like.
  2. Use the new Add-Ons SDK, only for Firefox 4. These ones doesn't require a restart and it's supposed to be future-proof.

In order to create a classic add-on you can get a skeleton using the Add-on Builder . There are lots of info about how to create these extensions and the API that they can use, and to start creating an Add-on the first step is this page to setup the environment. All you need is a text editor, some patience and be careful following the instructions. You can then configure Firefox to load the extension from the disk but when you make changes to the code you'll have to use an extension to force a reload of all the Firefox code or directly restart it; not nice.

To get started building add-ons with the new SDK, check the tutorial.
First problem: You are required to have Python installed.
What?
I'm so tired of projects that say: you have to install this or that or all of these projects just to get started.
What's so special about Python and the SDK environment that can't be done inside Firefox?
Why should I have to keep the list of instructions instead of being able to click on some buttons "Add extension", "Run tests", "Install", "Reload", etc...
Big boo here.
Maybe they want us to use wget instead of Firefox if they think that command line is so nice.

Anyway, I gave it a go in the Mac (I won't bother trying to install python in windows, it has already too many SDKs there for this and that), and so I followed the basic example, while trying at the same time to adjust it to my goal, I add the files, and when I do the "cfx run" then I get a cryptic error "raise ValueError('invalid resource hostname: %s' % name)". WTF? check again that I haven't done anything too weird. Nops. Then put back exactly the sample code. Nops. Search for the message. Bingo!, although there's no warning about this in the tutorial, you CAN'T use uppercase letters in the folder name. Hello Mozilla, it's 2011, I thought that the problems with uppercase and lowercase were gone long ago since MS-DOS. Why aren't your wonderful Python scripts able to deal with them?
Another big fail.

As a summary: I got a bad taste of the Add-ons SDK. When they put forward something that isn't oriented to Python lovers I might test it again (please note that I haven't even tested the API, just the environment makes me go back to keep using the classic method)

Chrome

It seems that there's a lot of work going on here in order to provide a very complete API for the extensions as well as good documentation and lots of examples. You can see a very basic one here and everything is quite easy to follow. Given the fast path that it's set on the release of new Chrome versions we can expect that this trend will continue and that they will add missing features to make some tasks even easier.

The only thing that you need is a text editor and Chrome, and by following the instructions you can get it working. It's not so powerful as the classic extensions in Firefox, but it's really easy to start creating an extension and there are lots of examples to check how they work.

Safari

It seems again that there's plenty of documentation at a central place, but just in the first page there's something strange:

Important: To develop extensions for Safari, you need to sign up for the Safari developer program online, at http://developer.apple.com. You need a signed certificate before your extension can be installed.

Uh?
So to create an sample extension in my own computer I need a certificate?

Ok, this shows again that Apple is a control freak. Why do I have to register to get an Apple ID and then get enrolled into a "Safari developer" program so that I can finally request a signing certificate, just to create a test extension? I can understand that in order to deploy it I might need to sign it, but I really should be able to create an extension for myself without the need to sign two looong agreements with Apple (I'm not sure if there was a paragraph about my first newborn there)

Anyway I go ahead and get a certificate in the Mac, and then it seems to work, but I would like to keep the development environment in Windows, so I try to install the downloaded *.cer there but anyway Safari keeps saying that there's no signing certificate installed. After a little while and some digging I realize that I must export the private signing key from the Mac KeyChain to Windows and once I installed it there Safari started working.

In some regards this might be the simpler interface of all the browsers in order to create an extension as you get a dialog to setup the basic configuration of the extension instead of editing them in a text file. The way that the code is setup is similar to Chrome (and Opera): background pages, injected scripts, so porting from Chrome wasn't a hard task.

As it happens with almost everything Apple does, if you are satisfied with what they offer, they try to make it quite easy, but if you want something extra then it's a no go.

Opera

I started checking the Opera API with the very first builds where they started adding support for extensions. In those days the API wasn't complete, there were a bunch of things that didn't work at all, so due to my hurry to test it I became a little frustrated because there were so many things missing, there was almost no documentation at the moment so it required a lot of effort to try to make something work because the examples were quite basic.

Now they have improved everything a lot, the behavior is similar to Chrome and Safari, but this is still a fresh SDK, so there are still missing features available in other browsers. They have written now lots of documentation and I guess that very shortly it should be quite easy to port an extension between Opera, Chrome and Safari due to the convergence of APIs that the developers find useful.

For the moment Opera it's lacking an API call similar to the ones that I've used for the other browsers so I will put the extension for browser at rest waiting for them to include them instead of struggle again and get tired of finding that it's not possible in any way.

2011/02/03

Mobile test

A quick test of the new blogger application for android

Seems to support only plain text and pictures. Doesn't list existing posts or labels

2011/02/01

WriteArea 1.0.1 Beta 1

Today I've uploaded a beta version of WriteArea to AMO, as I said, it has been updated to CKEditor 3.5.1 but besides that it includes (finally) a feature that it's the way that most of us expected the editor to behave: in-page editing.

This means that the editor is integrated into the page instead of a bottom pane or popup dialog. This feature is still experimental and there might be some unexpected problems, so please be careful (by saving drafts or copy&paste of the contents) before submitting the form.

This feature might have some improvements before the final release, but you can already start testing it

Some drawbacks (at least for the moment):

  • It's not possible to revert the action, once the editor is created it only goes away when the page reloads (might not be a big problem)
  • The clipboard operations are again restricted by default.
  • The Open/Save draft features are no longer available. Maybe I'll adapt them to use HTML5 storage instead of saving to file.

Benefits:

  • It's just easier to use and understand
  • There can be multiple editors in the same page
  • A button can be added so all the textareas are converted without using the context menu

Please, test it and tell me if you notice some problem or if you think that this is really the way to go and the other options should go away.

2011/01/24

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

 

 

2011/01/22

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.

2011/01/16

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'} } );

 

2011/01/15

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.