CakePHP helpers are so powerful that when you begin to hack helpers here and there you discover a lot of possibilities which can save you a lot of time. Same thing happened when I had an idea to AJAX'ify the forms using some shortcut.

Let's try hacking the FormHelper and enable AJAX. We'll use jQuery Form plugin to submit forms via AJAX request (I don't know any other good plugins for forms).

What we'll be doing:

Converting a normal form like below one, to make it call AJAX(using jQuery lib) and alert us when form posted:

1. Extend your FormHelper to something like AjaxFormHelper (Now normally I don't extend core helpers like this, but use a similar method similar to this (comment by grigri): http://cakebaker.42dh.com/2008/10/18/dont-abuse-the-apphelper-to-extend-the-core-helpers/#comment-110708 ) and overwrite create() method like this:

I'm not that good in explaining code flow, but you might have noted 3 get variables appended to our form action URL above. These variables are: 'ajax','flash_only' ,'js' and serves their own purpose that I'll tell in next steps.

2. Now we enable the AJAX in our form (CakePHP's $options array is so good that you can overwrite and modify almost many methods easily):

This will show a JS alert after form has been submitted successfully.

This will show an inline message after form has been submitted successfully.

Note that ajax=true parameter we sent in create() method. This will tell helper to load this form via AJAX.

3. Now your form will be AJAX ready (if you've included this AjaxFormHelper properly). But because our controller function was made to process normal POST function, and flash message on success – we'll have to change that behavior. This is what a normal JerksController::add() method should look like:

We don't need full action content from views/jerks/add.ctp to appear in response when AJAX is called. We can make this work traditional way by checking if it's an AJAX request in controller method itself and do needful, but I wouldn't want to modify all my controller functions to enable AJAX, so here's what I've come up with.

Remember the 3 GET variables above?

'ajax' => This one will determine if a given HTTP request is an AJAX request.

'flash_only' => This will tell if rendering should happen or not. Flash only means, after controller function is executed, do not render, just show flash message.

'js' => This is used for alert type, if this is not set, show inline alert. If set true, helper must show JS alert() on form success.

Inside your AppController::beforeFilter(), add this code:

Do not blame me for using GET variables, I found many issues with 'named' so I'm relying on normal GET variables.

Now you'll need to edit ajax.ctp layout file.

This should be self explanatory, even though this code definitely needs some refactoring. We're basically manipulating those 3 GET variables according to our need. In process, we're also checking validation errors occurred in form.

I have not used it under the production environment yet, so I'd really like to hear any pitfalls (if any) using this approach. Thanks for reading.

Abhimanyu Grover

While a routine research on net today I went to a security advisory site. I was reminded by this website that how easy it is, for script kiddies to hack into most of the outdated open source apps. It's not a new thing, but I feel importance of sharing my experience as a web developer. For instance, this website here has got a special section for web apps featuring latest vulnerabilities and potential security compromises: http://milw0rm.com/webapps.php

If one start browsing through it, will easily find everything from File disclosure attacks to SQL injections. And it's just not that, in most of the reported security issues, people have even published a test script or attacker code which can actually run from anyone's computer increasing number of possible attackers who are not just aware of the flaw, but are provided with the real tools now, to do what they want with a victim website. I've seen many websites went down in huge amount when such vulnerabilities are out in public. One of the biggest vulnerabilities in phpBB, an open source forum, was released few years back. It allowed any attacker to gain shell access to the victim website, and yes, I did tried it on my server before fixing the code. I seen like hundreds of websites went down in a matter of few hours. Later, the flaw was such a big hit to phpBB, that it was named as a worm. You can see BBC news article for stats etc. on it.

My clients ask me, 'this new open source technology is cool; we would like to go with it. What do you think?' I often stop and think for a second. Sometimes, I also try to explain them about positive and negative aspects related to it. I know decision to use open source technology will save time and budget anyway, so I keep decision on them most of the time. But I know it's not as safe as a custom-made app, I believe using something which is accessible to thousands of people comes with its own disadvantages (and advantages too, for that matter).

So should you really stop using Wordpress or Joomla or any other open source tech?

No, and Yes. First, you got to accept a thing. By choosing an open source app, you're keeping yourself a bit opened for attacks somehow – you have to accept that fact. But some good open source projects like Joomla, Wordpress, phpBB and many other with big communities are more responsive to such attacks, in just few hours when such vulnerability is out in public, they release security updates and have good platform to notify people using them. Sometimes these project owners are informed even before the attack is made public itself. Still, you can't trust a community if you are handling sensitive data or sensitive operations with your application. I wouldn't recommend any open source web app to any government institution, never ever for the same reason.

So, Open source with a backup of big community is good enough?

No matter how good a project's community might be or how bad, in any case, you have to keep your eyes open to such new vulnerabilities. If you've just launched an app, and kept it ignored on a server for months, you're likely to get hacked before any other active website. Remember, a good administration is must when using open source web apps. I highly recommend that either you keep an eye on such alerts or let your developers do the job. Like they say, Prevention is better than cure. Being proactive in preventing an attack is much easier rather than getting back online after your app is compromised because of some vulnerability.

What do we recommend?

• Keep an eye on security updates from project's website
• Always use the latest stable version of software, and update it timely
• Keep an eye on advisories boards or such website (Best thing, is to create a Google web alert to let you alert when something like this is out)
• Timely Automated backups

If you're not already doing it, I highly recommend you getting on it from today if you really care about your website. Hope this helps. Thanks for reading.

- Abhimanyu Grover

Every web developers uses mail() and spend some time testing if it is working or mail format is right or not. And when you have a big app which has a lot of emails to test, it can eat up a lot of time in testing.

Many developers use SMTP server running on their local host, others use some sort of complicated script, while others might be dependent on external SMTP servers for testing of outgoing mails from their web app. We were also using some sort of SMTP server for testing our outgoing emails, but if you want to see the best way to do so, here's this:

Test Mail Server tool

The program listens on localhost on a SMTP port (usually 25, may be changed). All mail sent to this tool is automatically stored and optionally opened with your mail client.

This cool tool will save you extra time opening your mailbox everytime after you carry out an email test or something. It has worked great for me.