Tuesday, August 21, 2012

Orbeon Forms 4.0 M10

Today we released Orbeon Forms 4.0 M10 (Milestone 10). Like 4.0 M9 and the previous milestones this is not a final release.

We have addressed the following issues in this build:
  • Form Runner
    • Don't allow "dot" in app/form name in page flow
    • PDF template: support output of file metadata for file attachments
  • XForms engine
    • "Prefix for xxforms:separator is not declared" (#418)
    • Security improvements (see blog post)
      • More robust encryption
      • Use item position instead of encryption
      • Hash function configurable via properties
    • More fixes for "Namespace interference with xs:*" (#331)
    • Allow xxforms:get-request-path() to be used after XForms initialization
    • "Save request parameters and headers to the dynamic state" (#422)
    • "XHTML output: `Accept` header lost upon submission" (#424)
  • Other
    • Initial implementation of "Protect pages and services by default" (#75)
    • Email sending: global properties for username, password, encryption, and smtp-port
    • Orbeon Forms now builds on Oracle JDK 7
    • Upgrade Commons Lang library
    • Refactoring of HTTP connection code
More information is 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.

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, August 15, 2012

More security improvements

Photo by buschap
Following up on changes making the upload control safer, we recently committed improvements to cryptography-related features within Orbeon Forms.

Orbeon Forms doesn't rely very much on encryption in the first place. That's because a lot of information is created and stays on the server, without ever making it to the client.

But there are a few instances where some data is encrypted on the server and sent to the client. For example, when an upload is terminated, the server tells the client to dispatch an event back to the server. That event should not be tampered with.

Besides encryption, there are cases where hash algorithms are used. Some are purely internal, for example for caching within the XForms engine. Others are mostly cosmetic, for example to make unique random document ids look nice (still, in general you want to use a proper hash algorithm as an added layer of safety on top of a random generator).

So we have reviewed the cryptographic algorithms we are using. Some of them were no longer current and we have upgraded them and made some aspects configurable. For example, you can specify the length of the AES encryption key and specify the hash algorithm to use.

Due to some export restrictions from the US, the strongest encryption algorithms are by default not available in the JVM (see the Unlimited Strength Jurisdiction Policy Files provided by Oracle to enable stronger algorithms). So by default, we choose reasonable strength and algorithms, but you can specify stronger keys and algorithms via properties.

Besides the algorithms, we have also taken some steps to follow good encryption practices. For example, we now make better use of salting to generate the encryption key, to make sure that it is different every time the applications is restarted.

Finally, we have made changes related to XForms selection controls item values. The XForms engine used to encrypt item values before sending them to the client. This way item values remain confidential by default (even though in many cases item values are not private information).

However, it is not trivial to do encryption right in this case, without giving away some information about the items (for example, if your encryption algorithm is not initialized properly, one might figure out that two items have the same value).

The good news is that here we can avoid encryption altogether by sending item positions instead! This is not confidential information, the server already knows items by position, and we avoid complex encryption logic.

For more information, see the new configuration properties.

Stay tuned for more security-related features for Orbeon Forms 4.0!

Tuesday, August 7, 2012

Orbeon Forms 4.0 M9

Today we released Orbeon Forms 4.0 M9 (Milestone 9). Like 4.0 M8 and the previous milestones this is not a final release.

We have addressed the following issues in this build:
  • Form Runner
    • Not found error with noscript error summary (#405)
    • Summary page: form title/description no longer shown (#408)
    • Error summary uses improved "visited" mechanism
    • Fix email sending for binds using ref attributes
    • Windows only: upload is not working (#414)
  • Form Builder
    • Disable unpolished keyboard shortcuts (#407)
    • Windows only: upload is not working (#414)
    • Renamed repeat loses ability to set min/max (#417)
  • XForms engine
    • XHTML output contains redundant xmlns="…" attributes (#400)
    • XHTML output: JavaScript error with loading indicator (#403)
    • Date and time formats don't take language into consideration (#409)
    • Namespace interference with xs:* (#331)
  • Other
    • XIncludeProcessor outputs redundant namespaces (#402)
    • Build: remove dependence on com.sun.image.codec.jpeg (#326)
More information is 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.

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, August 1, 2012

Choosing web technologies

Photo by ladyvee9
Back when we started Orbeon we didn't have to think too much about which technology to choose given our background: Java was cool then, it was king on the server, and we had worked with it before it even reached version 1.0. But that was maybe the last time we didn't have to choose anything as far as technologies are concerned!

For example, can you pick anything you would call a clear winner in the following categories:
  • Web frameworks in Java
  • Web frameworks in other programming languages
  • Client-side frameworks (low-level)
  • Client-side frameworks (high-level)
I think that the closest we can get to an easy technological choice, in the sense of a technology with a large market share and which is also considered good stuff, is maybe jQuery, "used by over 55% of the 10,000 most visited websites". But, even that is not what one would call an obvious technological choice. And for everything else, the level of consolidation remains fairly low.

There is currently a huge rebirth of interest in programming languages, and these days you don't even have that clear of a choice as far as programming languages are concerned anymore.

Not that this is bad: the fact that there is so much going on is very exciting, and it probably means that software will remain interesting for a very long time.

So today more than ever you have to be careful when choosing technology. Here are a few things we think about when choosing technology:
  • Did it come out just yesterday, or does it have a few years behind it and a strong community?
  • Is it just cool because of fashion or hype, or does it solve a real problem?
  • How much effort is it going to cost us to integrate that technology?
  • Does it integrate nicely with your existing technologies (unless you are starting from scratch)?
  • Are big companies using it (and by this I don't mean IBM, but maybe Twitter)?
  • As a programmer, are you going to be happier using it?
As mentioned earlier, this is the kind of considerations that have led us to choose Scala, CoffeeScript, LESS, jQuery, and very recently, Twitter Bootstrap.