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.

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:

1. Open the Preferences dialog (Intellij IDEA menu -> Preferences)
2. Under “IDE Settings” select “Plugins”
3. Click the “Browse Repositories” button.
4. In the search box type “wicket”, which should narrow the results significantly.
5. Right-click “Wicket Source”, and select “Download and Install”.

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:

setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new HttpsConfig(HTTP_PORT, HTTPS_PORT)));

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:

public class LoginForm extends StatelessForm
{
    public LoginForm(String id)
    {
        super(id);
        add(new TextField("username").setRequired(true));
        add(new PasswordTextField("password").setRequired(true));
    }

   @Override
   protected void onComponentTag(ComponentTag tag)
   {
       super.onComponentTag(tag);
       String action = urlFor(LoginFormHandlerPage.class, null).toString();
       tag.put("action", action);
   }
}

Now we’ll need to create a page to handle the form submission:

@RequireHttps
public class LoginFormHandlerPage extends WebPage
{
    public LoginFormHandlerPage(PageParameters parameters)
    {
        HttpServletRequest req = (HttpServletRequest) getRequest().getContainerRequest();
        String username = req.getParameter("username");
        String password = req.getParameter("password");

        if (loginSuccessful(username, password))
        {
             if (! continueToOriginalDestination());
             {
                 setResponsePage(AccountPage.class);
             }
        }
        else
        {
            getSession().error("login failed"));
            // on failure send user to our regular login page
            setResponsePage(LoginPage.class);
        }
    }
}

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.

First of all, the imports have all been moved in 7.x.  Here’s where they landed:

import org.eclipse.jetty.plus.webapp.EnvConfiguration;
import org.eclipse.jetty.webapp.WebInfConfiguration;
import org.eclipse.jetty.webapp.Configuration;
import org.eclipse.jetty.webapp.WebXmlConfiguration;

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">

<Configure id="wac" class="org.eclipse.jetty.webapp.WebAppContext">
    <New class="org.eclipse.jetty.plus.jndi.EnvEntry">
    <Arg>jdbc/mydatasource</Arg>
    <Arg>
        <New class="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource">
            <Set name="Url">jdbc:mysql://localhost/mydatabase?characterEncoding=utf8</Set>
            <Set name="User">username</Set>
            <Set name="Password">password</Set>
        </New>
    </Arg>
    </New>
</Configure>

Normally this goes into src/main/webapp/WEB-INF, but you probably don’t want to deploy that with your app in your production war file. So instead I put mine in src/test/jetty/jetty-env.xml. You’ll need to modify your Start.java to tell Jetty to find the relocated config file.

EnvConfiguration envConfiguration = new EnvConfiguration();
URL url = new File("src/test/jetty/jetty-env.xml").toURI().toURL();
envConfiguration.setJettyEnvXml(url);
bb.setConfigurations(new Configuration[]{
    new WebInfConfiguration(),
    envConfiguration,
    new WebXmlConfiguration()
});

I found that I also had to set a couple of environment properties:

System.setProperty("java.naming.factory.url.pkgs",
                   "org.eclipse.jetty.jndi");
System.setProperty("java.naming.factory.initial",
                   "org.eclipse.jetty.jndi.InitialContextFactory");

With this, I can finally access my JNDI datasource happily from Wicket/Jetty.

Update: I’ve created a gist with the full source code.

Fear not! The Sonatype checksum search REST service can give you the Maven coordinates based on the jar’s SHA1 hash.

Still too much work? Not to worry, I just wrote a quick program to make it even easier for you. Provenance will take a directory full of jar files and write out the XML dependency information for every jar it finds. You can then copy/paste this right into the <dependencies> section of your pom.xml.

Enjoy.

Here’s a handy way to add a Git SHA to all your app’s pages via Wicket and Maven.

Maven

First, we’ll use the exec-maven-plugin to create a git.properties file for us. Add this to the <plugins> section in your pom.xml:

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>exec-maven-plugin</artifactId>
   <version>1.1</version>
   <executions>
       <execution>
          <phase>compile</phase>
          <goals>
             <goal>exec</goal>
          </goals>
       </execution>
   </executions>
   <configuration>
       <executable>git</executable>
       <arguments>
            <argument>log</argument>
            <argument>--pretty=format:gitsha=%H %ci</argument>
            <argument>-n1</argument>
       </arguments>
       <outputFile>target/classes/git.properties</outputFile>
   </configuration>
</plugin>

This will create a git.properties file containing the Git SHA, along with the commit timestamp whenever your code is compiled. You can learn how to further customize this here.

Wicket Application Subclass

Now we’ll need to read in the git.properties file when our application starts up.

public class Application extends WebApplication
{
    private String gitSHA;

    public AppgravityApplication()
    {
        java.util.Properties props = new java.util.Properties();
        try
        {
            props.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("git.properties"));
            gitSHA = props.getProperty("gitsha");
            log.info("gitsha: " + gitSHA);
        }
        catch (IOException e)
        {
            log.severe(e.getMessage());
            gitSHA = "unknown";
        }
    }

    public String getGitSHA()
    {
        return gitSHA;
    }

Wicket WebPage Subclass

Now we’ll create a WebPage subclass that renders the Git SHA into a <meta> tag when the page is rendered.

public abstract class MyPage extends WebPage
{
    @Override
    protected void onBeforeRender()
    {
        Label metaGitSHA = new Label("metaGitSHA", "");
        metaGitSHA.add(new AttributeModifier("content", Model.of(((Application) getApplication()).getGitSHA())));
        addOrReplace(metaGitSHA);
        super.onBeforeRender();
    }
}

You’ll want to extend MyPage for each of your pages. You’ll need to add the placeholder meta tag to each of your HTML pages like this:

<head>
    <meta wicket:id="metaGitSHA" id="metaGitSHA" name="metaGitSHA" content=""/>
</head>

And you’re done!

It’s built in Wicket and tiny bit of JQuery. It’s fairly basic, but it has one fairly novel feature- you can add textual annotations to your uploaded images; the annotations appear as actual searchable text, rather than merely being part of the image bits.

I’m planning to add features like:

• HTML5 drag-n-drop for uploads
• upload multiple pictures at once to create an album
• user comments

Today I figured it out- I had paused my web history some time back. On a whim I tried unpausing it, and lo and behold, Maps now works again in Safari. Pausing it again results in the same breakage, so the problem is repeatable. Having to enable Web History to use Maps is a little unsettling, but this sounds like a bug.

In order to create memorable passwords I took the Diceware approach. The idea is simple: create a list of English words, and assign a five digit number to each of them.

23542 click23543 cliff23544 climb23545 clime23546 cling23551 clink

To build up a password, you select some number of these words and combine them (preferably with some further randomization of the case, as well as perhaps inserting some digits or symbols between the words).

To select each word, you roll a die (or fire up a pseudo-random number generator) five times. If you roll 2, 3, 5, 4 and then 3, that corresponds to the word with index 23543. In our case, that’s cliff. Keep selecting words in this manner until you’ve built up a sufficiently long/complex password.

There are a number of password generator sites that seem to be using lots of server-side entropy for password generation, but then blithely download the generated passwords across the Internet to your browser. That doesn’t seem like such a good idea. With create-a-password, it all happens right in your browser window, thanks to the magic of GWT.

On the downside, the dictionaries used for word selection are in fact downloaded (and they are well-known anyway). Despite this shortcoming, it still seems safer to me than shipping generated passwords across the network. Using a longer password (Wikipedia recommends 5 or more dice words) can help with this.

Diceware dictionaries are available in several languages, so it was pretty straightforward to go ahead and use GWT’s i18n to make this program available in a few different languages. Hopefully I haven’t butchered the Spanish too badly.

I was a little disappointed to learn that GWT doesn’t seem to support automatically recognizing the user’s browser locale. I expected to be able to automatically detect this, and then offer localized content, but that doesn’t seem to be the case. I ended up having to embed a property into each of my localized html pages:

<meta name='gwt:property' content='locale=fr'/>

Another approach is to use a JSP. Despite this, I think it turned out pretty well.