The customer (a big retail store chain) uses micro sites to implement small, time-limited areas in their web site. This proof of concept demonstrates, how the desired life cycle of a micro web site for social media activities could be realized with Openshift 2.x. The life cycle includes development, test, publish and archive. Another important aspect of this proof of concept is the scalability of the solution.
Vaadinator generates a vaadin-based User Interface (both mobile and Desktop), backend and testing facilties from an annotated Domain class. It borrows much from the Domain Driven Design idea. Our intention is to get people productive with vaadin and excited about vaadin – even those who never worked with it before. Vaadinator is free and open source (Apache 2.0-licensed).
The POODLE bug (CVE-2014-3566) affects nearly everything and everybody is trying to secure all of their systems. That includes your JBoss servers. Securing your JBoss 4 or 5 has one pitfall, which I am going to explain in this post. Apart from that it’s easy.
I stumbled on this issue when securing the web interface of a customer’s JON server. (Important note: the following snippet will not work around POODLE for communication from JON server to JON agent!) JON is by default configured to use TLS, so there is a poodle protection installed by default.
Yeahh, well… let’s verify that:
echo "" | openssl s_client -ssl3 -connect your.server.dns.or.ip:7443
Surprise, surprise: Even with TLS configured the SSL-Session using SSLv3 was established successfuly!
SSL-Session: Protocol : SSLv3 Cipher : DHE-RSA-AES256-SHA Session-ID: XXX Session-ID-ctx: Master-Key: XXX Key-Arg : None Krb5 Principal: None Start Time: 1413471616 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate)
The cause for that is that the tomcat configuration doesn’t work as I would expect it. The following configuration does NOT do the trick (server.xml of the deployed tomcat):
<!-- Does NOT work! --> <Connector port="7443" address="0.0.0.0" protocol="HTTP/1.1" scheme="https" ... secure="true" SSLEnabled="true" sslProtocol="TLS" ... > <!-- Does NOT work! -->
The RedHat guys actually posted the solution but it’s easy to mistake the important point. The following configuration bans your evil poodle:
<Connector port="7443" address="0.0.0.0" protocol="HTTP/1.1" scheme="https" ... secure="true" SSLEnabled="true" sslProtocols="TLSv1,TLSv1.1,TLSv1.2" ... >
Ok there is one obvious (and also important!) difference and one subtle difference. The obvious one is that it is
"TLSv1,TLSv1.1,TLSv1.2" and not
"TLS". By the way
TLSv1.2 is only available from JDK 1.7 on.
But there is also the subtle difference of a single “s” which is very important, because without it it does NOT work. To make it clear, it will only work with
"sslProtocols" and will NOT work with
That is confusing for me because I have never seen that option documented but the documented option seems to have no effect at all. So I suspect there is a typo in either the code or the documentation.
Hope I could help you somehow! If you’ve got any questions feel free to comment on this post. Good luck on your poodle fighting!
In general, every software solution requires a roadmap, as the basis for targeted further development and so it can be adapted to users’ needs in the coming years. No matter which niche the software serves, it always represents a form of reliable standard for its users. As a result, features are rarely removed, since this is perceived as a loss and impacts user acceptance.
Normally, the product manager is responsible for planning and marketing software. This person is the product-market expert for his or her specific area. The product manager develops a product strategy, known as the roadmap. Software releases are generally implemented in the form of a project, with the help of a project manager. Project and product managers provide each other with significant support by sharing their experiences.
The JBoss EAP / Wildfly application server provides as primary API the EJB client library to invoke remote EJB components. This client library is the implementation of the WildFly application server to invoke EJB components. The lookup of an object, such as a JMS connection factory, from the naming service is with the EJB client library not possible. For this purpose the remote naming implementation can be used. It can handle lookups of objects from the naming service. Both libraries can be used through the InitialContext of the JNDI API.
This post introduces three ways to configure the InitialContext to lookup and invoke EJB components, describes the pro and cons of each approach and introduces a combination of both libraries.
In the previous post we focused on some useful runtime metrics, which are of interest when monitoring your application server and applications. This post introduces the management clients provided by the JBoss EAP / Wildfly Application Server to manage and configure server instances.
The JBoss EAP / Wildfly provides a powerful concept for management, configuration and monitoring of the JBoss Application Server itself and its Java EE Applications. The concept is based on the detyped management API. All management clients of the application server use this detyped management API to interact with the server.
In this post we focus on some useful runtime metrics which are of interest when monitoring your application server and application with the Command Line Interface (CLI).
We report our best practices for conducting moderated remote usability tests. Like a step-by-step tutorial, we want to enable you to manage your own remote usability test. We evaluated the tutorial internally and other team members could reproduce a remote usability test with almost no transfer costs.
Usability tests in an agile world
Some months ago, we had the idea to develop a virtual UX lab that supports us in collecting user feedback on the fly as early as possible. First, we thought about a tool for unmoderated usability tests. Unfortunately, there was no tool that met our requirements. Most tools that do a great job (e.g., http://www.usabilitytools.com) are cloud-based solutions and require public access to the prototype. This is a no-go for our industrial clients that try to get a competitive advantage with the software we develop for them.
Moderating tests avoids information loss
Another reason that let us reorient towards remote moderated usability tests was the loss of information density if the participants do not have to think aloud and if you are not able to ask questions for further insights. If you conduct only a few tests, you want to get as much information as possible. Andreasen, Nielsen, Schrøder and Stage (2007) showed in their paper “What happened to remote usability testing? An empirical study of three methods” that unmoderated usability tests detected less usability issues than moderated remote or lab usability tests. Continue reading