A new version of the library packed, with a fair share of new features.
We bumped the mid-version number, not only because this release brings a lot of new functionality to the plate, but, we also did some changes that may require existing users to be modified — read the release notes carefully.
A new namespace Wt::Auth contains services, model and view classes to implement a state-of-the art authentication system in your web application. It contains password-based authentication, implementing best practices, remember-me cookies, email confirmation, and authentication using third party identification services such as Google, based on the upcoming OpenID Connect and OAuth 2.0 protocols. We appreciate any feed-back on the API or features.
We are planning to include the authentication module in JWt for the next release (3.2.1).
The HTTP client handles HTTP and HTTPS protocols, and can be used for POST or GET requests. In its current state, it was developed mainly to be useful for implementing the OAuth 2.0 protocol, but we plan to expand its features to cover most use-cases for an HTTP client within the scope of a web application.
While this will not replace all use-cases of more expansive libraries such as curl, the implementation has one clear advantage: the client is implemented using asynchronous I/O, and uses the same thread-pool as used for processing requests. This avoids tying up threads while waiting for downstream servers.
The Mail client implements (a subset of) the SMTP protocol to send mails. As for the HTTP client, in its current state, it was developed mainly to be useful for implementing email confirmation for the authentication module, but we plan to expand its features to cover most use-cases for a mail client within the scope of a web application. It does support proper Unicode handling in recipient names, message title and plain or HTML body texts, which already is a benefit over many alternative libraries.
We also added a Json namespace that deals with JSON deserialization (and later, also serialization).
Denial-of-Service mitigation. We have added two measures which can be configured to prevent DoS attacks that try to exhaust the server by spawning sessions. This is in particular a risk when deploying using the progressive bootstrap method, since then a plain HTML session can be spawned with a single request.
Plain sessions may be limited to be only a fraction of the total number of sessions (most legitimate sessions are Ajax-enabled)
Compromised session ID risk reduction: would a session ID be compromised (even though it is well protected, especially when using HTTPS), it can in many cases no longer be used to hijack that session.
A full page refresh (using the session ID to rerender the current application state) is no longer allowed unless both client IP address and user-agent are unchanged. To still enable page refresh in this situation, you may configure the use of a cookie which can be used to confirm the original browser (although that cookie will not be used for session tracking). You may even chose to disable this feature entirely by specializing refresh().
The session ID cannot be used to POST events to an Ajax session, since these require proof of other ever-changing context specific information, notably a pageId and ackId.
A detailed description of the security features of Wt and JWt will be the topic of a blog post by itself.
The release contains many other improvements. Besides the usual improvements to widgets, we have also some changes specific to the C++ or Java versions:
Wt (C++): This version comes with many reorganizations, including a more flexible (and useful) logging system, deferred response rendering, new template features and other additions including a Firebird backend for Wt::Dbo. We have also bumped our WebSockets implementation in the built-in httpd server to include support for the newest draft specifications of the protocol.
JWt (Java): We have now implemented logging within the library using SLF4J, which allows you to plug the JWt logging into your own logging framework of choice. In this version, we have also cleaned up the servlet-2.5 versus servlet-3.0 support: the same JWt application can now be deployed in a Servlet 2.5 or Servlet 3.0 container. When deployed in a Servlet 3.0 container, async support may be enabled and this will be used to implement server push in a more scalable way. JWt is now also available in the central Maven repository.