Wednesday, June 27, 2012

The right cookie

Your browser makes two types of HTTP requests to Orbeon Forms:

  • Page requests, done to load your form, as an HTML page.
  • Ajax requests, done after the form is loaded, in the background, to dynamically update the form as users interact with it.

Since version 3.8, released in May 2010, Orbeon Forms checks that a valid session is present before processing Ajax requests. This is done as a security measure. Consider this scenario:

  1. Alice is logged into your application. She loads a form in a first tab of her browser and another form in a second tab.
  2. Now in the second tab, she clicks on a link to log out, and forgets to close the first tab before leaving the computer unattended.
  3. An intruder, Mallory, comes in and gets access to the computer. he won’t be able to load a new form without logging back in, but what about the form in the first tab?
    • Pre–3.8, Mallory would have been able to interact with the form, as long as no new page was loaded, possibly accessing data or performing changes he is not authorized to do.
    • With 3.8 onward, Orbeon Forms checks that a valid session is present with Ajax requests, so Mallory won’t be able to do anything with that form in the first tab, .

The session is maintained by the servlet container or application server (e.g. Tomcat) using a cookie, typically JSESSIONID. That cookie is set the first time the browser requests a form, and then sent in subsequent requests, including Ajax requests.

JSESSIONID cookie received in form request and sent in Ajax requests
JSESSIONID cookie received in form request and sent in Ajax requests

If you have some kind of proxy between the browser and Orbeon Forms, you need to make sure that the session is properly kept, and if you’re investigating a cookie issue, tools like Firebug or the Chrome Dev Tools will help you, allowing you to see the cookies received and sent by your browser. Assuming Orbeon Forms is deployed on http://www.example.com/orbeon, the first time your browser requests the page, the server will set the cookie with the following header in the response:

Set-Cookie: JSESSIONID=1122315805F64E5505CC048C1CCBE00E; Path=/orbeon

Make sure the path in that cookie (here /orbeon) corresponds to the the beginning of the path to your form, as you see it in the URL. If it doesn’t, the browser will ignore that cookie. Then as you interact with the form, you will see requests made to http://www.example.com/orbeon/xforms-server. Those are the Ajax requests mentioned earlier. Check that the same cookie initially set when the first form was loaded is also sent in those Ajax requests:

Cookie: JSESSIONID=1122315805F64E5505CC048C1CCBE00E

If it isn’t, this is maybe because the Ajax request is sent to a different host than the one from which the form was loaded, or that the path in the Ajax request, here /orbeon/xforms-server doesn’t start with the Path for that cookie, here /orbeon.

And for some background information on how cookies work in browsers, you might want to check the Implementation section, on the Wikipedia page about HTTP cookies.

Tuesday, June 19, 2012

Neat and informative error reports with Errorified

Photo by Juhan Sonin
Nobody likes to see an application crash, but when it happens, it's better to have useful information about what went wrong.

A very long time ago, we implemented nicer stack traces in Orbeon Forms, but this did not transfer into nicer information in the server logs. Recently, with the introduction of run modes, we have enforced more strictly the default behavior that users should never see exceptions (of course developers should see them!). So it is even more important that detailed information be logged on the server.

This is what we have done with a little utility we call Errorified. We set it up as a separate repository on github so it can be used independently from Orbeon Forms.

What Errorified does is prepare a neatly-formatted report of what went wrong. This includes Java stack traces, but also, optionally, application-specific stack trace information. In the case of Orbeon Forms, this might include the line numbers in an XForms document.

There are a few other cool things about Errorified:
  • When there are multiple nested exceptions, common parts of the stack traces are not shown.
  • You can set a maximum of stack entries to show for a given trace segment, and the extra entries are elided when needed.
  • It's able to find the cause of exceptions that don't support Java 1.4's getCause() method.
  • It's written in Scala.
You can see a sample report here. There are many ways that this can be improved, so feel free to suggest your own!

Monday, June 18, 2012

Orbeon Forms 4.0 M4

Today we released Orbeon Forms 4.0 M4 (Milestone 4). Like 4.0 M3, this is not a final release, but a preview release for those of you who want to see what's coming up in 4.0 and send us feedback.

In this release we have addressed a number of issues, including:
  • Fixes to Form Builder publish
  • Fixes related to showing error messages for visited vs. non-visited fields
  • The tinyMCE rich text editor now works in portlets and is used everywhere
  • Ability to embed fonts used when filling out fields in PDF templates
  • For developers, we have now much nicer server-side error logging
We have also started a few changes which are not visible in this build yet. We have added initial support for Twitter's Bootstrap library. In particular, buttons now feature Bootstrap classes and appearances.

More details are available in the in-progress release notes for 4.0.

You can download the builds using these links:
Don't forget to grab a trial license for the PE version.

We plan to release the next milestone builds again at one-week intervals, on June 25 and July 2.

Please send feedback preferably to the ops-users list or via twitter (if short!), or feel free to comment on this blog entry if appropriate.

Friday, June 15, 2012

Form Builder's new UI to edit labels and hints

For every form field you create in Form Builder, you’ll be entering a label. And maybe, you’ll also enter a hint, typically a few words shown below the field, to provide more guidance for end users. When creating forms, you’ll be editing lots of labels and hints. So for Orbeon Forms 4.0 we’ve focused on making the label and hint editing super fast and intuitive.

After you add a form field, the next thing you’ll most likely want to do is to edit its label. So when you add a field, where the label would be, Form Builder shows a text field for you to type the label. Form Builder also positions the cursor in that text field. For instance, after adding a date field, you’ll see:

Empty label
Empty label

As soon as you start typing your text shows instead of the grey hint Type your label here. When done, press enter, and the label shows without the text field:

A label was entered
A label was entered

To edit a label just click on it, and a text field shows again. To give you a hint that you can click on the label to edit it, when your mouse pointer gets close to the label, Form Builder highlights it:

Label highlighted
Label highlighted

If, when creating the form field, you didn’t enter a label, or later removed it, in place of the label you’ll see a greyed out Click to add a label. And of course, the same logic also applies to hints. So our control with an empty label and hint shows as follows:

Without label and hint
Without label and hint

The new Form Builder label and hint editor will ship with Orbeon Forms 4.0, and you can already try it today by downloading a 4.0 milestone build.

Monday, June 11, 2012

Orbeon Forms 4.0 M3

Today we released Orbeon Forms 4.0 M3 (Milestone 3). Like 4.0 M2, this is not a final release, but a preview release for those of you who want to see what's coming up in 4.0 and send us feedback.

In this release we have addressed a number of issues with Form Builder, in particular:
  • exceptions and a memory leak when adding controls to a section
  • error upon loading a form with custom XML and invalid XPath expressions
  • issue whereby you couldn't attach an image the first time you tried
  • enabled the help editor
  • missing hint editor under IE 8
  • a few usability fixes
The Form Runner proxy portlet had issues in M2, which are fixed as well! We have tested the proxy portlet and the full portlet in both Liferay 6.0.6 CE and Liferay 6.1.0 CE GA1.

Behind the scene, we have also rewritten part of the XForms engine event handling code. This allows us to address a number of issues related to events and XBL components. We also refactored a good part of XForms instance handling to help further maintenance and help us address some issues.

More details are available in the in-progress release notes for 4.0.

You can download the builds using these links:
Don't forget to grab a trial license for the PE version.

We plan to release the next milestone builds again at one-week intervals, on June 18 and June 25.

Please send feedback preferably to the ops-users list or via twitter (if short!), or feel free to comment on this blog entry if appropriate.

Wednesday, June 6, 2012

More secure file uploads

Image by John Trainor
Orbeon Forms does pretty well with file uploads: in particular, it supports uploads in the background, repeated uploads, and allows you to process uploads with other controls and submissions.

But file uploads are tricky business, with security implications. For example, you don't want a web application to have indiscriminate access to a user's files. (This is why, with web browsers, uploads always require a user action via a file selector or drag and drop.)

It's interesting to notice that XForms uploads go a bit further than HTML uploads: once a file has been selected by the xf:upload control, the application can do a number of things with it. For example, say you are uploading an image, and want to display it to the user immediately:
<xf:upload ref="."/>
<xf:output mediatype="image/*" ref="."/>
Yup, that's it. Pretty easy, right? All the magic is handled by the XForms engine. And that's exactly how the Orbeon Forms image attachment control work.

This works because there is a local URL representing the uploaded file. In Orbeon Forms, this does not directly point to the user's file. First, that would be impossible, as the browser doesn't give you access to that. Second, the file is transferred to the server first. So it is available on the server as  a temporary file: URL, until the form does something with it, such as showing it to the user or saving it to a database.

But what if somehow the file: URL was exposed to the user of the form (for example, say the form author by mistake used xf:input instead of xf:output)? The user might be able to tamper with the URL and gain access to other files on the server. That is unlikely to happen, and only if the form author makes a mistake, and only if the app server or server configuration authorizes the file access, but that would be bad.

So in the upcoming Orbeon Forms 4, we have made this process more secure. Every file stored by xf:upload now comes with an authentication code (MAC). So a URL now looks like this:
file:/foo/bar.tmp?
 filename=bar.png&
 mediatype=image%2Fpng&
 size=1234&
 mac=2db6140c988970391e8cd1513af3cc3a3dbcf6ff"
This allows internal consumers of the file URL to check the signature first. For example, xf:output only dereferences the URL if the MAC is correct. Any tampering of the URL done by an entity which is not xf:upload is rejected.

As a reminder, it is crucial, when deploying Orbeon Forms, to always setup a new Orbeon Forms password with the oxf.xforms.password property! Don't miss this easy step!

Monday, June 4, 2012

Orbeon Forms 4.0 M2

Today we released Orbeon Forms 4.0 M2 (Milestone 2). Like 4.0 M1, this is not a final release, but a preview release for those of you who want to see what's coming up in 4.0 and send us feedback.

In this release we have fixed some important issues related to attachments: there were bugs in M1 preventing saving attachments both from Form Builder and Form Runner, including PDF templates.

We have also addressed a long standing issue whereby Form Builder attachments were not published alongside the form.

In addition, there are new usability improvements in Form Builder, including visual feedback upon inserting radio buttons and labels. Those are little things but they count!

The details are available in the in-progress release notes for 4.0.

You can download the builds using these links:
Don't forget to grab a trial license for the PE version.

We plan to release the next milestone builds at one-week intervals, on June 11 and June 18.

Please send feedback preferably to the ops-users list or via twitter (if short!), or feel free to comment on this blog entry if appropriate.