According to a recent research paper by the Aspect Security Group, entitled The Unfortunate Reality of Insecure Libraries, “Eighty percent of the code in today’s applications comes from libraries and frameworks, but the risk of vulnerabilities in these components is widely ignored and under appreciated. A vulnerable library can allow an attacker to exploit the full privilege of the application, including accessing any data, executing transactions, stealing files, and communicating with the Internet. Organizations literally trust their business to the libraries they use.” When validating user input from forms and exposed services, we often ignore the URL or think to ourselves, “that information is validated later, it’ll be fine,” but when hacks like the following start turning up – in common web-frameworks – it’s time to start thinking seriously about URL validation. Fortunately, it’s easy to accomplish using a number of methods, but first, let’s look at how these attacks work.

This is the third article in the series of Creating a Facebook App with Java. In the first and second articles we set up a number of tools, and used the Facebook JavaScript API to retrieve our personal account information, as well as some information about our friends. In this article we will set up the Web Service (in Java) that will house all of our game logic. Remember we want to maintain separation of concerns, so if you ever find yourself putting if statements, or other logic in your html pages, you may be doing something that will be expensive or time-consuming to change later. After our Web Service is set up, we’ll start to tie our webpages to it, and then build out our actual game!

The first article in our series took care of setting up and installing an IDE, some tools, and signing up for your new app at Facebook. Now we’ll begin creating the Web application with a landing page and some basic Facebook API calls. We’ll be creating our web application using Forge – where we left off in the part one. Because Forge allows us to start our new application very easily, and streamlines things like adding persistence (and eventually Arquillian, the testing framework) with a single command.

We’ve all heard of “mobile apps” that are sweeping the internet – stories of developers creating hit apps in their parents basements, or while having coffees at Starbucks. They strike it rich, quit their jobs, and retire wealthy before the age of 25; but first, lets set some reasonable expectations. Those stories do happen, and they make the news because they’re fun to hear about, but you might want to consider playing the lottery for some better odds if you really think you’re next. I strongly believe that mobile apps (and/or HTML5 webpage apps) are the future of software development. Beyond that, social media is going to keep playing a greater and greater role in these applications. This article will take you through setting up a new Facebook app, from beginning to end. It is assumed that you are a developer, and as such are working on some UNIX based platform (all examples in this article will be from Ubuntu 11.10). Those working on Windows (like I may have been just last year) will have to find equivalent commands for certain parts. It is worth noting here that I am not a JBoss employee, nor am I affiliated with them in any way. However I am friends with several of their lead developers, which probably helped my initial gravitation in that direction. You will see me reference JBoss projects many times throughout this tutorial, and while you are always free to use your own alternatives, you may need to deviate from my instructions to do so.

It’s quite simple really. All you need to do is install Apache HTTPd, then set make sure you have a few modules installed and set up: Instructions below are for Ubuntu, Fedora, RHEL, or other Linux distributions. So what are you waiting for? Let’s get our JBoss / Apache love on.

When my family comes together for special occasions, it is official tradition to begin, fill, and end any given evening with a debate on social justice, politics, science, religion, or a combination of the above. This year was no different, with our post-feast discussion ranging from human rights to geological timelines of carbon fuel consumption rates. The topic that interested me the most, however, was HR 3261 – new “Anti-piracy” legislation from the MPAA and RIAA, currently making its rounds through congress.

The MPAA and RIAA are trying blacklist websites, block IP addresses, and change fundamental assumptions about the market we operate in – all under a new law that will tie the hands of the internet…

For those of you who are unfamiliar, this is a bill, quote, “To promote prosperity, creativity, entrepreneurship, and innovation by combating the theft of U.S. property, and for other purposes,” perhaps better known by its short name, the ” Stop Online Piracy Act.” It is an interesting piece of potential law, and in brief summary, increases the responsibility of internet companies to prevent copyright theft on their domains. It also stands to reason that because this bill was sponsored by representatives working with the MPAA and RIAA, that’s who’s going to use it, though I’m sure new powers and interested parties will line up to take advantage of the bill as soon as they find out how. But I’ve got news for you: Intellectual property is dying, and there’s nothing you can do about it.

Seizing the opportunity of a new Executive Committee (EC) under a new regime, I’d like to issue a call for reform of the Java Community Process (JCP) to allow it to produce more iterative and timely technology and live up to it’s name as a “community process”, rather than acting as the “corporate process” many believe it is today [1].

The PrettyFaces team is pleased to announce the release of PrettyFaces 3.3.0. PrettyFaces is an OpenSource Servlets extension with enhanced support for JavaServer Faces – JSF 1.1, 1.2 and 2.0 – enabling creation of bookmark-able, pretty URLs. PrettyFaces solves the “RESTful URL” problem elegantly, including features such as: page-load actions, seamless integration with faces navigation, dynamic view-id assignment, managed parameter parsing, and configuration-free compatibility with other web frameworks.

Features & Enhancements:

• Performance improvements when running JSF 2.0 in project stage ‘development’
• Regular expression performance improvements provided by Yann Simon.
• Ambiguous View IDs are now resolved automatically when using pretty:mappingIds in action method navigation, <h:link> and <h:button> component outcomes
• Ambiguous View IDs may now be resolved manually for outbound URL rewrites by adding ‘?com.ocpsoft.mappingId=…’ to URLs before calling HttpServletResponse.encodeURL(…)
• Dynaview URLs* are now resolved during rendering of links and navigation cases, and are now as functional as traditional mappings.

Bugfixes:

• Fixed bug that caused path parameter validators to be ignored (#102)
• Handle java.lang.ClassFormatError during initialization of bean name resolvers (#101)
• Also check Weld 1.1.x specific servlet context attribute while search for BeanManager
• Mapping inheritance now working correctly for mappings using the same viewId

* – Previously, DynaView URLs would only function on inbound requests, and once the method was evaluated, the value would be processed and then abandoned. For example, when rendering <h:link /> components, users would actually see the dynaview method definition rendered as their url! That is not a good experience, so in resolving the problem, we simple evaluate the dynaview method a second time (or as many times as necessary) in order to render the desired link target. And we do this using…

Do you have an existing Maven-based Java EE application that you’d like to clean up a bit in the browser? Do your URLs look too much like this: http://example.com/app/sillyServletName/someStuff?sillyParam=22&sillyOtherParam=profile And not enough like this? http://example.com/app/profile/22 Are you building a new application, and don’t want to sacrifice anything when it comes to usability or SEO capabilities? Well, URL-rewriting is your answer, and it’s easy to get started, even easier using JBoss Forge.

So Java EE 6 is out, and you’ve decided to give it a go. You’re trying to port an existing application over to the new stack (or are trying to create a new one for the first time,) but exceptions are bursting through the seams and you just can’t seem to get things to work. If you’re familiar with Spring and Hibernate (with all the joy that is OpenSessionInView or OpenSessionInConversation,) more than likely the problems you’re having are related to the Java Persistence API (JPA), combined with Enterprise Java Beans (EJB). Contexts and Dependency Injection (CDI) should be a familiar face if coming from Spring, but things are subtly different in the world of Java EE.