OCPsoft

Migrating from PrettyFaces to Rewrite – Simplicity meets power

Daniel Sachse — Sat, 04 May 2013 17:04:32 +0000

Hi Java web-developers. I hope you are already familiar with PrettyFaces. If not, I will give you a very short introduction taken from the project documentation:

PrettyFaces is:

“The open-source /url/#{rewriting} solution for Servlet, JSF, and Java EE, 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.”

Rewrite, on the other hand, is a URL-rewriting framework built for extendability, for use with any web-framework or pure Servlet itself, and is used for the core of PrettyFaces “4.0″ – bringing the best of both worlds… so that sounds very cool thus far, but what do we want to achieve with it? Why would we use either of these frameworks?

Just compare these two URLs:

Very ugly one :

http://www.example.com/blog.html?author=w0mbat&post_id=23&year=2012

A very pretty one :

http://www.example.com/blog/w0mbat/2012/23

This is something that both PrettyFaces and Rewrite can accomplish for us, but what if, for example, we wanted to intercept all URLs and require a login? This is where PrettyFaces can no longer help us, but rewrite is ready to come to our aid!

Why migrate?

PrettyFaces itself is really great but the configuration is not runtime dynamic. There is a feature called “DynaView”, which can be used to determine the page to display for a given URL-mapping at runtime, but it is fairly limited and is difficult to use when things get hairy. To achieve some level of dynamism, one can implement what is called a “RewriteProcessor,” but it’s basically all manual coding; there are no dynamic rules that one would need to e.g. display a login page for every requested URL if the user is not logged in.

This is only one of many cool features that Rewrite offers in comparison to PrettyFaces.

In this post we are going to migrate a PrettyFaces project which is NOT annotation based. We just use the pretty-config.xml to map everything.

Part 1 : Stock-taking

I created a small JEE 6 sample webapp with JBoss Forge which you can fork or clone from Github if you want. This application will show us several things:

a small pom.xml with only a few dependencies
an XHTML template to be DRY
four pages: index, about, profile, login
a WEB-INF/pretty-config.xml

We will start with our pretty-config.xml shown below:

WEB-INF/pretty-config.xml

This file just maps / to index.xhtml, /About to about.xhtml and /Profile to profile.xhtml. The pages just have links to each other, to provide some sort of interaction. Nothing too special

Below you can see some content of the index.xhtml to get an idea of how the navigation with PrettyFaces works:

/src/main/webapp/index.xhtml

All the other files(web.xml, faces-config.xml,..) are pretty straight forward and you can check them out via Github.

Part 2 : Migration

The easiest way to migrate to Rewrite, is simply to use the Rewrite PrettyFaces compatibility module. Remove any PrettyFaces dependencies that you may have in your project, then include the following dependencies. First we will have to change the pom to exclude PrettyFaces and include Rewrite:

/pom.xml


	org.ocpsoft.rewrite
	rewrite-servlet
	2.0.0.Final


   org.ocpsoft.rewrite
   rewrite-config-prettyfaces
   2.0.0.Final

That’s it! You’re done. You’d now using PrettyFaces with Rewrite core, but since you probably want to know a little bit more about how to use the power of Rewrite, let’s continue and learn how to replace our PrettyFaces configuration with Rewrite completely. We’ll also learn a few tricks that Rewrite can help us with.

Migrating the configuration

First, delete your pretty-config.xml, but keep it somewhere you can look at while you move the functionality over to Rewrite.

Now, we need to create several ConfigurationProvider classes. These classes have to extend org.ocpsoft.rewrite.servlet.config.HttpConfigurationProvider (for servlet environments.) A ConfigurationProvider has a method which returns a priority and a method which returns the Configuration. Have a look at the AccessRewriteConfiguration below:

at.w0mb.prettyMigration.rewrite.AccessRewriteConfiguration

package at.w0mb.prettyMigration.rewrite;

import javax.servlet.ServletContext;

import org.ocpsoft.rewrite.bind.El;
import org.ocpsoft.rewrite.config.*;
import org.ocpsoft.rewrite.servlet.config.*;

public class AccessRewriteConfiguration extends HttpConfigurationProvider {
	@Override
	public Configuration getConfiguration(final ServletContext context) {
		return ConfigurationBuilder.begin()
				.addRule(Join.path("/").to("/index.xhtml"))
				.addRule(Join.path("/about").to("/about.xhtml"))
				.addRule(Join.path("/profile").to("/profile.xhtml"))
				.addRule(Join.path("/login").to("/login.xhtml"))

				// Authentication
				.defineRule()
				.when(Direction.isInbound().and(Path.matches("/logout")))
				.perform(Invoke.binding(El.retrievalMethod("identity.logout"))
						.and(Redirect.temporary(context
							.getContextPath() + "/")));
	}

	@Override
	public int priority() {
		return 10;
	}
}

With this Configuration, we mainly implemented what we saw earlier in the pretty-config.xml; but we have also defined a ‘virtual’ URL that doesn´t map to an *.xhtml file, but rather, invokes a bean method that performs the logout and redirects to /.

Question: What happens if we try to invoke the application now?!? No idea? Ok.

Answer: We will get error messages because JSF cannot find any mappings for our ourcomes e.g. pretty:about, pretty:profile, …

So what do we need to do now? We have to do the mapping ourselves in the faces-config.xml:

WEB-INF/faces-config.xml



   
   
		*
		
			pretty:home
			/index.xhtml
		
	
	
	
		*
		
			pretty:about
			/about.xhtml
		
	
	
	
		*
		
			pretty:profile
			/profile.xhtml

The application would nearly work now as we have written it. But how about the login? We will define another ConfigurationProvider as shown below.

First, though, we will need to add another dependency to our POM. This will enable us to @Inject our Identity object directly into the configuration. The rewrite-integration-cdi extension module, enriches our rewrite configuration objects with CDI support, and gives us access to the Unified Expression Language (not shown.)

Exhibit 5


	org.ocpsoft.rewrite
	rewrite-integration-cdi
	2.0.0.Final

at.w0mb.prettyMigration.rewrite.LoginInterceptor

package at.w0mb.prettyMigration.rewrite;

import javax.inject.Inject;
import javax.servlet.ServletContext;

import at.w0mb.prettyMigration.Identity;

import org.ocpsoft.rewrite.config.*;
import org.ocpsoft.rewrite.servlet.config.*;

public class LoginInterceptor extends HttpConfigurationProvider {

	@Inject
	private Identity identity;

	@Override
	public Configuration getConfiguration(ServletContext arg0) {
		ConfigurationBuilder config = ConfigurationBuilder.begin();

		if (!identity.isLoggedIn()) {
			return config
					.defineRule()
					.when(DispatchType.isRequest().and(Direction.isInbound())
					.and(Resources.excluded()))
					.perform(Forward.to("/login"))
					.addRule(Join.path("/login").to("/login.xhtml"));
		}

		return config;
	}

	@Override
	public int priority() {
		return 0;
	}
}

As a final step, we have to tell Rewrite which ConfigurationProvider classes to use at runtime:

META-INF/services/org.ocpsoft.rewrite.config.ConfigurationProvider

at.w0mb.prettyMigration.rewrite.LoginInterceptor
at.w0mb.prettyMigration.rewrite.AccessRewriteConfiguration

Part 3 : Conclusion

We are now able to call our application under http://localhost:8080/prettyMigration and we will see our login page. This page gets displayed no matter which URL we will call. After clicking on ‘login’ we will be ‘logged in ‘ and redirected to the index page. Once we open http://localhost:8080/prettyMigration/logout, we are ‘logged out’ and we will again see the login page.

You can grab this project from Github. The project was build and tested on JBoss 7.1, in my opinion the fastest and most advanced application server on the market.

I hope you liked my first post on this blog and if you have any comments/questions/improvements, please just post a comment here or contact me!

About the author:

Daniel 'w0mbat' Sachse is a Senior Software Engineer and IT Consultant and works as a Freelancer at his own company called Wombat Software Technologies. He mainly works on Java EE Web Applications as a Developer or Architect but also gives IT Training in this area. He also contributes to JBoss Forge and some of its plugins. This blog represents his personal thoughts and perspectives, not necessarily those of his customers.

Daniel is also member of the 'JSR 346: Contexts and Dependency Injection for JavaTM EE 1.1 ' expert group.

Set up an anti-spam filter for your website with mod_security and fail2ban

Lincoln Baxter III — Wed, 03 Apr 2013 15:27:25 +0000

Frequently spammers target products such as wordpress, web forum software, phpMyAdmin, and other common tools used by hobbyist and professional website administrators.

Whether you are hosting your own blog, or running a website for your company or more, it can be difficult to deal with the increasing amount of malicious web traffic seen on a daily basis, while still allowing friendly crawlers such as Google, Yahoo, and MSN search engines.

This harmful and wasteful traffic may damage your system or simply waste its resources, slowing down the site for your more welcome users. If this sounds familiar to you, but your page hits don’t seem to add up, then you may want to consider taking some of the measures outlined below in order to secure your site from harmful hacks and sluggish spam.

Get set up

First things first, of course – installation is where we begin. mod_security and fail2ban are not new technologies, so we will be turning to some existing tutorials for our first getting started steps. We will then continue to tweak these tools to allow traffic from search engines and friendly crawlers. There is a fantastic tutorial on how to set up mod_security over here at thefanclub.co, which I highly recommend using if you are on a debian/ubuntu system.

If you are on Fedora, RHEL, or CentOS (eww), then the setup is a little bit simpler for mod_security and for fail2ban; however, you will still want to install the OWASP mod_security core rule set (crs).

You should definitely install the OWASP mod_security core rule set unless you simply want to write your own rules.

Once you have installed and configured mod_security, and installed fail2ban, you will need to configure fail2ban to read the mod_security audit file. Once completed, you are ready to start tweaking!

CRITICAL: Add your current IP address or IP range to the fail2ban whitelist or YOU COULD BE LOCKED OUT OF YOUR SYSTEM. See, “using the fail2ban whitelist.”

Now restart Apache HTTPd and let’s get started.

/etc/init.d/apache2 restart

Tweaking mod_security to allow googlebot, yahoo, and msn

There are a few things that we do NOT want to do with mod_security, and the first of which is block search engine’s crawlers when they try to access our site. Their log entries will look like the example below, which creates a difficult situation. Because the IP address is informationally logged in a format that fail2ban will later pick up and try to block, we will need to find a way to prevent logging, or tell fain2ban NOT to block it.

--7f70c037-A--
[08/Apr/2013:10:43:17 --0400] UWLXhH8AAAEAAHFfJ@QAAAAD 66.249.73.107 46478 67.23.9.184 80
--7f70c037-B--
GET /not-there HTTP/1.1
Host: ocpsoft.org
Connection: Keep-alive
Accept: */*
From: googlebot(at)googlebot.com
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Accept-Encoding: gzip,deflate

--7f70c037-F--
HTTP/1.1 404 Not Found
X-Powered-By: PHP/5.3.10-1ubuntu3.4
X-Pingback: http://ocpsoft.org/xmlrpc.php
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 5986
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

--7f70c037-H--
Message: Warning. Pattern match "(?:(?:gsa-crawler \\(enterprise; s4-e9lj2b82fjjaa; me\\@mycompany\\.com|adsbot-google \\(\\+http:\\/\\/www\\.google\\.com\\/adsbot\\.html)\\)|\\b(?:google(?:-sitemaps|bot)|mediapartners-google)\\b)" at REQUEST_HEADERS:User-Agent. [file "/etc/modsecurity/activated_rules/modsecurity_crs_55_marketing.conf"] [line "22"] [id "910006"] [rev "2.2.5"] [msg "Google robot activity"] [severity "INFO"]
Apache-Handler: application/x-httpd-php
Stopwatch: 1365432196888162 1004514 (- - -)
Stopwatch2: 1365432196888162 1004514; combined=6736, p1=442, p2=6031, p3=0, p4=0, p5=261, sr=163, sw=2, l=0, gc=0
Producer: ModSecurity for Apache/2.6.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.5.
Server: Apache/2.2.22 (Ubuntu)

--7f70c037-Z--

As we can see in the example above, mod_security is logging when crawlers visit our website and experience 404 errors (and other problems.) This means that any time googlebot or another crawler is logged in such a manner, they will be banned, even though the traffic is valid. That’s not good, so we can take an arguably risky step to modify the mod_security configuration to allow our crawling friends.

Replace the rule action block with the action pass. This tells mod_security not to immediately block a request where something looking like a search bot is involved, but rather keep adding up the attack score until it reaches the threshold.

NOTE: This may actually be somewhat bad for security, however, since it is possible to fake the criteria on which these rules match. Spammers may actually masquerade as googlebot and friends! But this still enables mod_security to block the request using its attack score mechanism, while preventing log scraping tools such as fail2ban from blocking the IP addresses of the crawler – perfection has not yet been achieved.

/etc/modsecurity/activated_rules/modsecurity_crs_55_marketing.conf

# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.2.5
# Copyright (C) 2006-2012 Trustwave All rights reserved.
#
# The OWASP ModSecurity Core Rule Set is distributed under 
# Apache Software License (ASL) version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------


# These rules do not have a security importance, but shows other benefits of 
# monitoring and logging HTTP transactions.
# --

SecRule REQUEST_HEADERS:User-Agent "msn(?:bot|ptc)" \
        "phase:2,rev:'2.2.5',t:none,t:lowercase,pass,msg:'MSN robot activity',id:'910008',severity:'6'"

SecRule REQUEST_HEADERS:User-Agent "\byahoo(?:-(?:mmcrawler|blogs)|! slurp)\b" \
        "phase:2,rev:'2.2.5',t:none,t:lowercase,pass,msg:'Yahoo robot activity',id:'910007',severity:'6'"

SecRule REQUEST_HEADERS:User-Agent "(?:(?:gsa-crawler \(enterprise; s4-e9lj2b82fjjaa; me\@mycompany\.com|adsbot-google \(\+http:\/\/www\.google\.com\/adsbot\.html)\)|\b(?:google(?:-sitemaps|bot)|mediapartners-google)\b)" \
        "phase:2,rev:'2.2.5',t:none,t:lowercase,pass,msg:'Google robot activity',id:'910006',severity:'6'"

Look for other problems

You will also want to review the audit log and make sure that things look normal. If you are seeing a lot of outbound errors, it’s possible that you’ve been hacked. What is more likely, however, is that you have a bug in your web application and it is simply not playing nice with HTTP; you may not be completely standards compliant:

Found a match for 'Message: Warning. Match of "rx (

Tweaking fail2ban

When configuring fail2ban, you can test a failregex and ignoreregex patterns (as specified in our filter.d/modsec.conf) against the mod_security logfile before activating the fail2ban mod_security filter:

fail2ban-regex /var/log/apache2/modsec_audit.log "FAIL_REGEX" "IGNORE_REGEX"
fail2ban-regex /var/log/apache2/modsec_audit.log "\[.*?\]\s[\w-]*\s\s" "\[.*?\]\s[\w-]*\s\s"

Recovering from fail2ban – Unblocking an IP address

From time to time, you may sometimes need to un-ban an IP address, in which case, you’ll want this handy command, which tells IPtables to dump out a list of all current rules and blocked IPs to the console:

iptables -L -n

user@server ~ $ sudo iptables -L -n
[sudo] password for lb3: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ModSec  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
fail2ban-ssh  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ModSec (1 references)
target     prot opt source               destination         
DROP       all  --  77.87.228.68         0.0.0.0/0           
DROP       all  --  213.80.214.171       0.0.0.0/0           
DROP       all  --  70.37.73.28          0.0.0.0/0           
DROP       all  --  2.91.50.184          0.0.0.0/0     

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           
user@server ~ $

We can see that fail2ban is placing its rules in the iptables group fail2ban-ModSec. This is going to be important later, so write this down. You may then want to extract the IP address from this list so you can pass it to a command line by line:

iptables -L -n | grep DROP | sed 's/.*[^-]--\s\+\([0-9\.]\+\)\s\+.*$/\1/g'

And finally, we can pass it to the xargs command and perform the unbanning.

iptables -L -n | grep DROP | sed 's/.*[^-]--\s\+\([0-9\.]\+\)\s\+.*$/\1/g' | xargs -i{} iptables -D fail2ban-ModSec -s {} -j DROP

Conclusion

Please feel free to post comments, improvements, or extensions to this article. I hope that you now have a grasp on some of the fundamental principals of securing the website, while still allowing friendly traffic, but there is obviously a world of work to be done here to achieve a tolerant yet secure rule set.

Again, I recommend making sure that your whitelists are set up BEFORE you turn any of these features on. But once you do flip the switch, you should be happy with a faster, cleaner server.

This only scratches the surface of web application security, of which there are many types, from the server all the way to the application, but the more layers you can get that still work together for users nicely, the better. If you are interested in Java application level security, I have a few more posts on that topic.

About the author:

Lincoln Baxter, III is a Senior Software Engineer at Red Hat, working on JBoss open-source projects; most notably as project lead for JBoss Forge. This blog represents his personal thoughts and perspectives, not necessarily those of his employer.

He is a founder of OCPsoft, the author of PrettyFaces and Rewrite, the leading URL-rewriting extensions for Servlet, Java EE, and Java web frameworks; he is also the author of PrettyTime, social-style date and timestamp formatting for Java. When he is not swimming, running, or playing Ultimate Frisbee, Lincoln is focused on promoting open-source software and making web-applications more accessible for small businesses, individuals.

Setting up Google OAuth2 with Java

Matyas Danter — Tue, 26 Feb 2013 02:03:44 +0000

For all of you who are trying to figure out how to integrate with Google’s single sign-on functionality (like I’ve done for my own startup at tripgather.com), this article might be for you. I’ve taken the liberty of condensing all of the actual logic required to perform OAuth Google login, and provided it as a class and a JSP (seen below). In order to follow along better, I suggest cloning the example GitHub repository, and deploying to the application to your server of choice.

Assumptions

Familiarity with object oriented programming, Java, Maven, and Java EE
An IDE, it helps if you are comfortable using one (i.e. Eclipse)
Java application server listening on localhost:8080

Prerequisites

Google API Access credentials (Client ID, Client Secret). Set it up here https://code.google.com/apis/console/
Set up allowed Redirect URIs at Google API → API Access. Input: http://localhost:8080/OAuth2v1/index.jsp
The source code referenced in this article from GitHub.
A positive outlook on life.

Please use the link above to set up API Access Credentials. When you are finished, you will see a similar page to the one below. Use your Client ID/Secret from this page to replace the values of the String constants in GoogleAuthHelper.java.

Usage

Add Client ID, and Client Secret parameters to GoogleAuthHelper.java
Compile the project:
```
$ mvn clean install
```
Deploy war to application server
Browse to: http://localhost:8080/OAuth2v1/
Click "log in with google" on top of the page

1. Add Client ID and Secret

Replace the constants following constant values in GoogleAuthHelper.java with the values provided to you by Google API Access.

/**
 * Please provide a value for the CLIENT_ID constant before proceeding, set this up at https://code.google.com/apis/console/
 */
private static final String CLIENT_ID = "YOUR ID HERE";
 
/**
 * Please provide a value for the CLIENT_SECRET constant before proceeding, set this up at https://code.google.com/apis/console/
 */
private static final String CLIENT_SECRET = "SUPER SECRET SAUCE";

2, 3, & 4. Compile the Project, Deploy the WAR, Open that Browser

This is a Maven based project, so issue a Maven install command to build the project and assemble the war file from the root of the project (where the pom.xml file is located).

$ mvn clean install

When Maven is finished creating the web archive, deploy it to your favorite server and navigate to http://localhost:8080/OAuth2v1/

5. Click "log in with google"

Now that your app server is running, the application is deployed, and your web browser is pointed at the application’s context root, you will see a page similar to the one below. I double dog dare you to click that log in button. You know you want to.

After successful authentication you will see the page below, but there are a few important things to notice:

The URL changed, now it contains two request parameters, state, and code.
The page contains JSON output of your google account’s profile information.

Source Code

The authentication is possible thanks to the GoogleAuthorizationCodeFlow class. This class uses the Builder pattern to provide most of its functionality. GoogleAuthHelper’s no-argument constructor initializes the Flow using your client ID, secret, and other constants. The buildLoginUrl() method constructs the Google authentication URL based on the CALLBACK_URI and returns it as a Java String. This CALLBACK_URI must match one of the redirect URIs that you set up at Google’s API Access page. Upon successful authentication, OAuth2 will redirect you to CALLBACK_URI, and append the state and code GET request parameters to it. Please note, that the state request parameter is only to help differentiate authentication providers (i.e. Facebook OAuth, Google OAuth, or your own custom OAuth provider).

We need to use the code GET request parameter as the input for the getUserInfoJson(String authCode) method. If all is well, this method will return a JSON encoded Google profile as a Java String.

Here is the basic code that you can snip into your project:

index.jspView Complete File

<%
/*
 * The GoogleAuthHelper handles all the heavy lifting, and contains all "secrets"
 * required for constructing a google login url.
 */
final GoogleAuthHelper helper = new GoogleAuthHelper();
if (request.getParameter("code") == null
	|| request.getParameter("state") == null) {
	/*
	 * initial visit to the page
	 */
	out.println("log in with google");

} else if (request.getParameter("code") != null && request.getParameter("state").equals("google")) {

	/*
	 * Executes after google redirects to the callback url.
	 * Please note that the state request parameter is for convenience to differentiate
	 * between authentication methods (ex. facebook oauth, google oauth, twitter, in-house).
	 * 
	 * GoogleAuthHelper()#getUserInfoJson(String) method returns a String containing
	 * the json representation of the authenticated user's information. 
	 * At this point you should parse and persist the info.
	 */

	out.println(helper.getUserInfoJson(request.getParameter("code")));
}
%>

GoogleAuthHelper.javaView Complete File

public final class GoogleAuthHelper {

	/**
	 * Please provide a value for the CLIENT_ID constant before proceeding, set this up at https://code.google.com/apis/console/
	 */
	private static final String CLIENT_ID = "YOUR ID HERE";
	/**
	 * Please provide a value for the CLIENT_SECRET constant before proceeding, set this up at https://code.google.com/apis/console/
	 */
	private static final String CLIENT_SECRET = "SUPER SECRET SAUCE";

	/**
	 * Callback URI that google will redirect to after successful authentication
	 */
	private static final String CALLBACK_URI = "http://localhost:8080/OAuth2v1/index.jsp";
	
	// start google authentication constants
	private static final Iterable SCOPE = Arrays.asList("https://www.googleapis.com/auth/userinfo.profile;https://www.googleapis.com/auth/userinfo.email".split(";"));
	private static final String USER_INFO_URL = "https://www.googleapis.com/oauth2/v1/userinfo";
	private static final JsonFactory JSON_FACTORY = new JacksonFactory();
	private static final HttpTransport HTTP_TRANSPORT = new NetHttpTransport();
	// end google authentication constants
	
	
	private final GoogleAuthorizationCodeFlow flow;
	
	/**
	 * Constructor initializes the Google Authorization Code Flow with CLIENT ID, SECRET, and SCOPE 
	 */
	public GoogleAuthHelper() {
		flow = new GoogleAuthorizationCodeFlow.Builder(HTTP_TRANSPORT,
				JSON_FACTORY, CLIENT_ID, CLIENT_SECRET, SCOPE).build();
	}

	/**
	 * Builds a login URL based on client ID, secret, callback URI, and scope 
	 */
	public String buildLoginUrl() {
		
		final GoogleAuthorizationCodeRequestUrl url = flow.newAuthorizationUrl();
		
		return url.setRedirectUri(CALLBACK_URI).setState("google").build();
	}
	
	/**
	 * Expects an Authentication Code, and makes an authenticated request for the user's profile information
	 * @return JSON formatted user profile information
	 * @param authCode authentication code provided by google
	 */
	public String getUserInfoJson(final String authCode) throws IOException {

		final GoogleTokenResponse response = flow.newTokenRequest(authCode).setRedirectUri(CALLBACK_URI).execute();
		final Credential credential = flow.createAndStoreCredential(response, null);
		final HttpRequestFactory requestFactory = HTTP_TRANSPORT.createRequestFactory(credential);
		// Make an authenticated request
		final GenericUrl url = new GenericUrl(USER_INFO_URL);
		final HttpRequest request = requestFactory.buildGetRequest(url);
		request.getHeaders().setContentType("application/json");
		final String jsonIdentity = request.execute().parseAsString();

		return jsonIdentity;

	}
}

Next Steps

If you haven’t already downloaded the code and run it, I suggest you do that before bringing it into your codebase. There are a few Maven dependencies in the POM that you will need to include.

From here on, you may parse this information using Jackson, and persist it to a database or other data store. These are the basic building blocks with which you should be able to “get the stuff done.”

Resources and Links

About the author:

Matyas Danter is a Senior Associate at LiquidHub currently working at a large financial institution as a Production Support Specialist. He is interested in cryptography, software development awesomeness, and enterprise web applications.

JavaScript is the new Perl

Lincoln Baxter III — Fri, 04 Jan 2013 18:32:49 +0000

I don’t think we will see a “winner” of the browser-language wars any time soon, but there will be a winner. JavaScript hype is still through the roof, and with the discovery of a dynamic language in the browser actually works decently between late browsers, people are thoroughly excited; however, I’d akin this to people discovering Perl during the advent of C and C++. Does it work? Yes. Is it pretty? Not by a long shot.

Don’t get me wrong, I love Perl – I think it’s an incredibly powerful and fun language that now suffers from the bad reputation it acquired before gaining true object-oriented features – but, those who hate Perl hate it because it’s “too hard to maintain” and too “strange.” So if you want to talk about a strange language, look at JavaScript – it’s like Perl times ten. At least Perl has a consistent type inferencing and enforceable namespacing! (I think you’d have a hard time arguing that enforceable namespacing is a bad thing… global variable collisions can result in some pretty nasty bugs, particularly because it is easy to never see the downstream impact.)

Point being? As someone who has already gone through several language hypes and paradigm shifts in Computer Science (even in my relatively short 14 year experience,) JavaScript is a lot like Perl – extremely powerful, but a potential maintenance nightmare if one is not extremely diligent – and while I do like both languages, JavaScript just waiting for the next technology to come around and make it look like Perl does today: pervasive, but lacking enterprise adoption on large applications.

Follow the author on Twitter: @lincolnthree

Let’s take a moment to talk about Perl.

Perl was never as popular as JavaScript has become lately, partly because we never had a reason to popularize Perl in startup culture – where a teenager in his bedroom can make the next twitter craze – and partly because technology was just not as hot or nearly as pervasive back then.

If you look at the current trends, Perl is actually being replaced on a fairly large scale by Python and Ruby (other dynamic languages,) which, depending on who you ask, solve some of the maintenance problems and complaints that people have of Perl, and JavaScript is very likely to go through the same life-cycle – to be superseded by Dart, or maybe a non-backwards compatible mode of ECMAScript. In the mean time, to work around some of these issues, JavaScript is still being used much like an Assembly language. (GWT, CoffeeScript, TypeScript all compile to JavaScript.)

Now where is JavaScript?

We are seeing a similar explosion of packages (libraries), like Perl did, which led to the development of CPAN (you could akin this to the jQuery plugin ecosystem, which is neither as formal, reliable, nor as convenient or automated.) There’s a similar explosion of JavaScript implementations on server side and in other languages, leading to issues with compatibility and runtime bugs. If you tried to use ActiveState Perl on windows, or JavaScript via Rhino in Java, then you know what I am talking about. This is improving now, but so has it also improved in Perl, which compared to JavaScript was far more stable.

Still don’t believe that JavaScript is the new Perl? jQuery and NodeJS modules, likened to a very distributed collection of Perl modules, are the glue that holds together the JavaScript ecosystem, provides browser compatibility, and it admittedly does a pretty good job; however, sooner or later, the lack of language constructs like truly enforceable namespace boundaries, and the general mess created when teams get a little bit bigger is going to set in. This is seen over and over as the new wave of developers comes into corporate life: Larger companies try out new technologies all the time, then decide it’s costing measurably, and switch back to a stack that is resilient enough to withstand sloppy code.

We are even seeing a re-emergence of age-old discussions on, “how to effectively architect large-scale applications”, and how to keep from falling into the same pit of snakes that’s been around for years – snakes that are now very long in the tooth. These are thoughts and principles apply to any programming language, really, Perl, Python, Java included – so if you think the revival of this discussion will produce different results for JavaScript, then I think you are forgetting human nature.

We ARE inherently lazy and most of us will ignore nearly any best practice or principle once “that deadline” gets too close. Nobody ever goes back to fix their mistakes once the project ends, or once they get rolled onto a new team. Java has been the only modern language to show moderate survivability when exposed to corporate laziness.

“So if JavaScript is doomed to become the next Perl like you say it is, then what do we do in the mean-time?”

We do what we have been doing all along, because these are necessary steps for advancement. We continue to invest both in JavaScript, but also in technologies like Errai and GWT – two technologies whos’ growth echoes of an early 2000’s Java.

We should be mindful of the fact that while JavaScript is HOT right now, it does actually have programmatic and strategic shortcomings that must not be forgotten, ignored, or “shooed” under the carpet. If you show me a long-term maintainable solution for JavaScript that enforces the team/feature barrier and holds up against “corporate meltdown,” due to incompetence and laziness as application size increases, then I’d be willing to entertain the idea of using it for a bigger project.

Keep trying the latest frameworks and cool UI plugins; keep trying to bridge the server-browser impedance mismatch; find what works and what does not – JavaScript is not going away. We still have Perl apps out there, and whatever replaces JavaScript as a dynamic language (think ECMAScript 6, unless a non-backwards compatibility mode is introduced) will probably be viewed similarly to Python or Ruby vs. Perl today. Backwards compatibility will be a problem for ECMAScript because it is necessary to enforce these constraints; it is not enough just make them “available.”

Still, you don’t see that many big Python and Ruby shops either (Google is an exception,) so unless ECMAScript offers some of the same safety features of Java, it will probably end up much like Python and Ruby – “A little better.” In all reality, though, there is a big part of the JavaScript -> Perl/Python/Ruby comparison that we’ve omitted from the story to this point.

Java.

Java has eclipsed most dynamic languages in the corporation. We see new statically typed dynamic languages on the JVM practically every day to provide some more programmatic sugar and flexibility, but on bigger projects, Java is king. Now apply this to the JavaScript picture and you get a slightly different flavor of the same result. Not only are we seeing experiments replacing JavaScript with a similar dynamic language (Dart, CoffeeScript, or maybe just some necessary enhancements to JavaScript itself,) but in order to support large projects, we are also likely to see a type-safe revolution in the browser as well.

GWT is a good start, but progress has been slow – just like Java was back in 2002. We’ve waited 10 years to see Java turn into the actually very useful and extremely powerful technology that it is today. Without a doubt, Java has the largest ecosystem of shared libraries in any programming ecosystem. Java has seen ubiquitous corporate adoption. Java is taught at most colleges and universities, and while you might try to make the point that “Python is being favored over Java” in some schools now, this is really not because of its technical capability, but more about teaching a more general set of programming knowledge that may or may not actually be useful in a business environment. Functional programming, variable interpolation, and the lack of a separate compile step make Python an appealing educational tool, certainly when combined with a shell language interpreter. This does not change what we use in the enterprise, in our daily jobs.

For example. When I graduated with my BS in Computer Science, before moving to Red Hat, I worked first at one of the top 5 American mutual fund companies; a big bank. I was tasked with something that nobody else had been able to do before, using Java, and I said, “Okay fine, I can do this easily in Perl.” So I did it.

Success? Or something else?

The result was a nice pat on the back for figuring it out – it was even deployed to production, but since I had left the team shortly before the release, nobody could figure out how to make changes to my scripts, didn’t think to come ask me when environmental changes caused a failure, and it got abandoned and re-written in Java. Was that a good reason to abandon Perl as a solution? Definitely not, but there’s a lot to be said for using a technology that is safe, using a technology that enforces ‘some’ good practices (“training wheels” of type-safety), and using a technology that is well known among the industry. This will be the reality for JavaScript and its corporate replacement, unless it can catch up soon.

In the end, JavaScript is good for us, just like Perl. It pushes us to do better, pushes us to think outside the box, and pushes us to think twice about what we have been doing in the past. It certainly has its place, we can’t ignore it, and we must acknowledge that it is very good at what it does; but, like Perl and Python, it’s not the end of the line. Until we get our hands on the still evolving ECMAScript 6, which may alleviate JavaScript’s enterprise problems, we still haven’t seen our “Java of the browser” yet, except wait, yes we have. It’s Errai and GWT.

See you in 10 years, JavaScript. Until then, I’m going to practice my Regular Expressions.

About the author:

2013 Holiday technology recap and predictions

Lincoln Baxter III — Mon, 24 Dec 2012 22:23:31 +0000

Happy holidays, I hope everyone is relaxing and having a great time with their families and loved ones. To help see out the last year, and ring in the new one, I’ve prepared a (hopefully relaxing) article on some trends we’ve seen in 2012, and what that could mean for us in the next year and years to come. So if you want to take a break from the holiday din, then head over to JAXEnter and check out my article. The technologies I discuss are Rewrite, OCPsoft’s own, and Errai, by Red Hat.

Be safe, and I’ll see you all in the new year, ~Lincoln

About the author:

[announcement] Guide to translate PrettyTime to your native language

Lincoln Baxter III — Wed, 05 Dec 2012 23:06:11 +0000

If you’ve ever looked for social-style date formatting for Java, to create timestamps like, “2 minutes from now” or “3 months ago,” PrettyTime is probably the tool you’ve ended up with, and as you might know, it supports over 25 languages and dialects – a great number to be sure. But what happens when you come across one of the over 4500 living languages that are not supported?

Well, then it’s time to do some translation, and in order to help you manage this task, we’ve created a guide to help you get through as quickly and easily as possible. When you’re done, you might even want to submit your translation back to us so that everyone else can benefit from your hard work. The guide covers this, too. It takes only a minute or so to read the guide and get started! Let us know how you do.

About the author:

[video] GWT and Errai UI Quickstart

Lincoln Baxter III — Fri, 02 Nov 2012 17:20:55 +0000

I wish I had a magic GWT + Errai quickstart tutorial for you. But in fact, I do! Check out this video, and the tutorial below, to start your adventure with client side HTML5 templating in GWT!

Get started

Check out this code using GIT: https://github.com/lincolnthree/errai-ui-demo

To build and deploy, simply cd errai-ui-demo and run mvn clean install. The resulting artifact will be in the target directory, and you can deploy this directly to JBoss AS 7.1.

Import into IDE and delploy

To work on the project in an IDE, I would recommend Eclipse with JBoss Tools (available in the eclipse marketplace,) or JBoss Developer Studio 5. The first thing you will need to do is import the project, then you will still need to run mvn clean install if you have not done so already – this builds the initial GWT javascript payload for Eclipse to push out with the exploded deployment, then deploy it to JBoss AS 7.1 and start the server. Once it is there, you can return to the command line and type, mvn gwt:run, which will launch GWT dev-mode.

Run Dev-mode

Once dev-mode comes online, you can access the application at http://localhost:8080/errai-ui-demo/?gwt.codesvr=127.0.0.1:9997

Hack on the code

You can make modifications to *.client packages and sub-packages while the server is running, and refresh the page to see your changes.

Additional documentation about Errai and Errai UI is available here: https://docs.jboss.org/author/display/ERRAI/Errai+UI

About the author:

[podcast] Lincoln Baxter and Kito Mann on Java

Team — Mon, 08 Oct 2012 15:15:09 +0000

Join Lincoln Baxter of OCPsoft and Kito Mann of Virtua, Inc. as they discuss several emerging projects in Java. The transcript and MP3 can be found at Virtua’s site. This podcast was recorded at JAXConf in San Francisco, 2012.

How to @Inject Enum values into CDI beans

Lincoln Baxter III — Wed, 19 Sep 2012 17:52:50 +0000

I was recently asked how to Inject a Java Enum into a bean constructor using CDI. This turns out to be a fairly interesting situation, because enums are not usually available for Injection.

The first attempt

As much as we would hope for this to work, it does not. Enums are not beans because they have no default constructor (hence CDI does not know how to construct them,) and there is no standard way to resolve which enumerated value should be injected by default (Unless there is only one value, but this is still not supported due to the lack of default constructor.)

Injecting an enum with a single value does not work.

public class InjectedObject {
   private MyEnum e;

   @Inject
   public InjectedObject(MyEnum e) {
      this.e = e;
   }
   
   public MyEnum getValue() {
      return e;
   }

   /**
    * Our enum
    */
   public enum MyEnum {
      ONE
   }
}

This will result in a deployment failure

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [MyEnum] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject public org.example.InjectedObject(MyEnum)]
	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:365)
	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:297)
	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:157)
	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:184)
	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:470)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:74)
	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:72)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	... 1 more

The solution

We must turn to producer methods in order to make this possible. It takes just a little bit of code, but it is possible, and very easy! The reason this works is because any value may be injected if it resolves to a unique set of qualifiers and types. You could even inject a java.lang.String using this technique.

Using @Produces to to inject an enum in CDI.

/**
 * @author Lincoln Baxter, III
 */
public class InjectedObject
{
   private MyEnum e;

   @Inject
   public InjectedObject(MyEnum e)
   {
      this.e = e;
   }

   public MyEnum getValue()
   {
      return e;
   }

   /**
    * A producer is required in order to {@link Inject} an Enum
    */
   @Produces
   public static MyEnum getEnum()
   {
      return MyEnum.THREE;
   }

   /**
    * Our enum
    */
   public enum MyEnum
   {
      ONE, TWO, THREE
   }

}

And there you have it! A perfectly functional method of injecting enum values in CDI. You will, however, need to make sure you know which type of enum you want to inject, and if you need multiple types, then you’ll need to create qualifiers for each value.

You could also use the built-in @Named qualifier

The @Named qualifier is a built in qualifying type that allows unique qualifiers to be created using String values.

Using the @Named qualifier to inject arbitrary values of the same type

/**
 * @author Lincoln Baxter, III
 */
public class InjectedObject
{
   private MyEnum e1;
   private MyEnum e2;

   @Inject
   public InjectedObject(@Named("ONE") MyEnum e1, @Named("TWO") MyEnum e2)
   {
      this.e1 = e1;
      this.e2 = e2;
   }

   public MyEnum getValue1()
   {
      return e1;
   }

   public MyEnum getValue2()
   {
      return e2;
   }

   /**
    * A producer is required in order to {@link Inject} an Enum
    */
   @Produces
   @Named("ONE")
   public static MyEnum getEnumOne()
   {
      return MyEnum.ONE;
   }

   @Produces
   @Named("TWO")
   public static MyEnum getEnumTwo()
   {
      return MyEnum.TWO;
   }

   /**
    * Our enum
    */
   public enum MyEnum
   {
      ONE, TWO, THREE
   }

}

We would not, however, be able to @Inject @Named("THREE") MyEnum e because we have not declared a producer with such a qualifier!

About the author:

New tutorial: Regular expressions

Lincoln Baxter III — Tue, 18 Sep 2012 18:21:47 +0000

Do you love regular expressions as much as I do?

Well even if you don’t, I am pleased to announce a new tutorial: “OCPsoft’s guide to Regular Expressions.” As part of an ongoing initiative to promote awareness of regular expressions, and how they are used both as a general technology, but also specifically as applied to the Java programming language, we will be continuing to add new example-based guides to this course.

Please feel free to post questions and comments if there are topics or specific problems that you would like to see addressed. We will do our best to answer your questions and share the knowledge!

Check out the tutorial.

Enjoy!
~Lincoln