Data-driven webapps built with Ruby, Java & Wicket

I started doing some Twilio development recently and ran into a problem with Adobe Flash. Twilio Client (which lets you make phone calls right from your browser) relies on the Flash plugin. It pops up this nice little settings dialog the first time it runs to ask your permission:

The problem is that on Chrome, it won’t let you actually click any of those buttons- the dialog is non-responsive to mouse clicks. This was really frustrating, and a few minutes of Googling showed that this was an old problem supposedly fixed by a Flash update months ago.

Updating to the latest Flash didn’t help (it’s apparently bundled with Chrome, and doesn’t use the version you can install manually on OSX).

Then I came across this trick: use tab to navigate the dialog checkboxes, and spacebar to select/deselect. Works like a charm.

The folks at 42lines have released an awesome Firefox plugin called “Wicket-Source”. It allows you to easily navigate from your browser to the corresponding Wicket source code.

Since their plugin is Eclipse-based, I wrote up a compatible plugin for Intellij IDEA. You can install it from the repository, or build it yourself from the source on Github.

There are two parts to this plugin: the Firefox extension (provided by 42lines) and the IDE plugin; you need both. To install the Firefox plugin, follow the directions from 42lines. Then to install the Intellij plugin do the following:

Open the Preferences dialog (Intellij IDEA menu -> Preferences)

Under “IDE Settings” select “Plugins”

Click the “Browse Repositories” button.

In the search box type “wicket”, which should narrow the results significantly.

Right-click “Wicket Source”, and select “Download and Install”.

You’ll be asked to re-start Intellij, and then you should be in business. The plugin uses port 9123 and no password by default (same as the Firefox plugin defaults). To change this, open the IDE Settings dialog and click “Wicket Source” to enter a password.

Lots of folks are making great use of Twitter Bootstrap, which includes a handy login button right at the top:

To protect your users’ privacy, you should make sure that form is sent over SSL. If the hosting page is https that happens automatically, but most domains don’t secure their entire site; only a subset of pages are typically secured with SSL. But since this header likely appears on all your pages, how can you secure the form?

The first step is to manually adjust the form’s action attribute to ensure that the form submission happens over https, rather than http.

But this is where we run into a problem with Wicket- if the hosting page is http, and you have also installed an HttpsMapper in your WicketApplication like this:

then Wicket will not allow your form to be sent over https; the mapper will notice the http/https mismatch, and instead of calling your form’s onSubmit() method, it will simply serve up the hosting page again, discarding your form submission.

The solution is to manually post your form to a different, secure page that is marked for https via @RequireHttps. Then the HttpsMapper will allow the form submission to take place.

First, we need a LoginForm that will adjust the form’s action attribute to point to our secure page:

Note that if you’re using Wicket 1.5.3 there is a bug that prevents the processing of form POST parameters (that’s why we’re reading the params manually from the HttpServletRequest). Fixed in Wicket 1.5.4.

The LoginFormHandlerPage will process the submitted form data over https, and if successful, log the user in, else send them to a page where then can re-enter their password.

You can get all the code (and quite a bit more useful login-related stuff) from github.

Credit where it’s due: the real gem here (submitting the form to a secure url) comes from this blog posting by Petri Kainulainen.