Raible Designs

AppFuse Refactorings Part III: Remember Me

This is a continuing series on what I'm doing to make AppFuse a better application in Winter/Spring 2004. Previous titles include: Changing the Directory Structure and Spring Integration.

- - - -
AppFuse includes a Remember Me feature that works with Container-Managed Authentication. In version 1.3 it works by setting a few cookies: username, password and rememberMe. The last one being a simple flag that the user wants to be remembered. Then a LoginFilter checks for the rememberMe cookie, and if present, logs in the user using the other cookie values. The obvious issue with this is that the password being sent and stored on the user's browser.

This was easily solved in Tomcat 4 by placing the form-login-page and form-error-page under a "security" directory and then setting cookies on the /appfuse/security path. This way, since no other part of the app can access /appfuse/security, these cookies can never be retrieved in any part of the application. The problem is that this didn't work in Tomcat 5 since it forwards to the login page (rather than redirecting). Since forwarding is obviously a better solution (user's can't bookmark the login page), I needed a new way to implement the Remember Me feature.

To my knowledge, cookies can only be stolen if someone is able to login to your AppFuse app and insert JavaScript to send the "document.cookie" value to an external URL. So for AppFuse, it's likely that stealing cookies is not much of an issue. However, for applications like Roller, it is an issue - since other bloggers on the same server (i.e. JRoller) could put JavaScript on their blog to grab cookies from other users.

Just as I was about to give up searching for solutions, along came Charle's persistent cookie strategy. Here's how I implemented it in AppFuse. Hopefully it follows all the rules and is a good solution. Here's what I did make it happen.

- - - -
Step 1: Setting the cookie.
Scenario: A user logs in and selects the "Remember Me" checkbox.
What Happens: When a user clicks the Login button, they submit to a LoginServlet that redirects them to "j_security_check" to take advantage of Container-Managed Authentication. This servlet is responsible for ensuring an SSL Login (if enabled), encrypting the user's password (if enabled) and also sets a session variable to indicate the user wants to be remembered. After authenticating, the user will hit the ActionFilter, where the following code sits:

In the above code snippet, the UserManager.createLoginCookie(username) method is responsible for creating a new cookie string and storing this information in the database.

The RandomGUID is a class I found on Java Exchange. Once the rememberMe cookie was set, I had to configure LoginFilter.java (mapped to form-login-page and form-error-page) to look for this cookie. This brings us to Step 2.

- - - -
Step 2: Using the cookie to login the user.
Scenario: A User has already logged in successfully with "Remember Me" enabled.
What Happens: When the login page is served up to the user, the LoginFilter is invoked and it checks the validity of the "Remember Me" cookie.

The UserManager.checkLoginCookie(value) method looks up a record based on the random GUID, and if it finds a match, it creates a new GUID and saves it in the database. If null is returned, it means the cookieId doesn't exist, and the login proceeds as it normally would. Below is the guts of the checkLoginCookie() method.

You can see from this, that if the lookup succeeds - a new cookieId is saved and returned. If a not-null cookieId is returned, the remember me cookie is updated, the user is looked up and the Filter forwards an authentication request (with username/password) to the LoginServlet. The Filter also sets an attribute to let the application know that this user authenticated via cookies. This is important so that cookie-authenticated users cannot change passwords. When using cookie-authentication, the password field is hidden and a message warns the user that they must logout/login to change passwords.

Lastly, I had to come up with a solution to remove these login cookies.

- - - -
Step 3: Allow the user to clear their login cookies.
Scenario: A User has already logged in successfully with "Remember Me" enabled.
What Happens: For this, I implemented a simple solution. When a user logs out, all persistent login cookies are removed.

I don't know if it's best to divulge the details of AppFuse's cookie login strategy. However - it *is* open source - so folks can find figure it out if they really want to. By exposing it to the world, I hope to get the most robust solution possible.

Next up, how I replaced Hibernate with iBatis. Using Spring, it only took me a few hours! Pretty slick, eh? ;-)

Tapestry looks very nice

While leaving a comment on my ActionForms: Struts' bastard child post, Erik Hatcher sounds like a broken record:

> When are you going to just quit asking questions and try out Tapestry? 
> You can build it from CVS HEAD easily or just grab a 3.0 binary (currently 
> beta, but way stable). Drop in the WorkBench WAR file and see for yourself.

So I took 5 minutes and downloaded and deployed the WorkBench WAR. Check it out if you like. Looks pretty nice to me. The DatePicker is pretty cool, but it shows up in the wrong spot on Firefox - and it's annoying that I can't close it just by clicking on the screen somewhere (like most popup calendars). Also the Chart doesn't work on my Linux box (it worked fine on Windows).

However, if you're looking for something like the DisplayTag, Tapesty has that. The URLs it constructs for everything look a little ridiculous though. I wonder if a Filter with smarts could pretty those up?

Google Ads

Google Ads are a good thing - it looks like they'll be covering my hosting/bandwidth costs. Sweet!

Mozilla Firebird 0.8 - I'm not impressed

I downloaded Mozilla Firefox (formerly known as Mozilla Firebird) for my Mac this morning and I'm definitely not impressed. I can't change the fonts and there's no scrollbar when I visit any sites. What a CF. As for Windows, I can't even download the installer. Too bad - this release had real potential.

[ANN] WebWork 2.0 and XWork 1.0 Released!

From the WebWork mailing list:

I'm pleased to announce the release of WebWork 2.0. You can download it
at:

https://webwork.dev.java.net/files/documents/693/2886/webwork-2.0.zip

XWork 1.0 has also been released and is available at:

https://xwork.dev.java.net/files/documents/709/2885/xwork-1.0.zip

Thank you to everyone who provided patches, support, and ideas for over
the past year to get this project from initial concept to completion. 

Congrats to all who lent a hand in getting this release out. We all know that releasing software is a great feeling - hope these guys enjoy a night or two of good sleep.

It looks like Spring 2004 is going to be a fun time - WebWork 2.0, Spring 1.0, JSF 1.0 (in March) and Tapestry 3.0 is right around the corner. It's a good time to learn a new web framework. Now if we could only get them to agree on something like their choice of expression languages and validation. ;-)

Off to Vegas!

I'm flying to Las Vegas in a couple hours for a weekend of booze, gambling and good friends. It's one of my best friend's (Shane Murphy) bachelor parties. There's 16 of use meeting there from various time zones. Most of us went to school together - and all the others I'm good friends with. Should be a great weekend with lots of laughs and reminiscing about old times!

Have a great weekend!

iChat AV can now talk to Windows users!

I've been waiting for this for quite some time now.

iChat AV v2.1 Public Beta adds support for video conferencing with the AOL Instant Messenger 5.5 for Microsoft Windows.

I've been waiting for Windows <-> Mac video-conferencing so Abbie can talk/see her grandparents all the time. My dad has been video-conferencing with my uncle for years - it's about time I got up to snuff and started using this stuff. Sweet - too bad I'm leaving for Vegas tonight and my dad is leaving for Africa tomorrow! Maybe I should buy an iSight tonight so I can talk to Julie over the weekend. Is there an Apple Store in Vegas?

AppFuse Refactorings Part II: Spring Integration

I took some time last weekend and refactored AppFuse to use Spring to replace my Factories and Hibernate configuration. It only took me a couple of hours, which says a lot for Spring. I was amazed at how many things just worked. It actually lifted me out of my flu symptoms and made me feel euphoric. Or it could have been the Sudafed. In reality, I only replaced one Factory class (DAOFactory) - a fairly large class that instantiated DAOs using reflection and constructor variable inspection. I was also able to get rid of the ServiceLocator class, the getConnnection() stuff in ActionFilter and the hibernate.cfg.xml file.

The one thing I found when looking at the Petclinic and JPetstore apps was that they used an applicationContext.xml file for unit tests, and a (very similar) one for running the app in a container. To me, this was a warning sign. DRY (Don't Repeat Yourself) is a big reason for using XDoclet and I'm beginning to think that Spring could benefit from a little XDoclet lovin'. Anyway, back to the story.

I wanted to find a way to use the same XML files for testing and in-container execution. As you might know from Part I, AppFuse has 3 different tiers: dao, service and web. To run unit tests for the dao and service layers, I simply load a applicationContext.xml file in my JUnit test's setUp() method and go from there. I saw this in the petclinic app and found that it works pretty well. In the end, I decided to setup different XML files for each layer - applicationContext-hibernate.xml, applicationContext-service.xml and applicationContext.xml for the web layer. The main applicationContext.xml uses entity includes to reference the other two files.

The main pain I found was that the entity includes required different paths for tests vs. running in container. Basically, for tests, I had to use:

<!ENTITY database SYSTEM "applicationContext-database.xml">

While tests, using the ClassPathXmlApplicationContext required:

<!ENTITY database SYSTEM "WEB-INF/applicationContext-database.xml">

Using Ant to do a little replace logic allowed me to jump over this hurdle.

Using this setup, any new DAO definitions are added in src/dao/org/appfuse/persistence/hibernate/applicationContext-hibernate.xml, new Manager definitions (and declarative transaction settings) are be added in /src/service/org/appfuse/service/applicationContext-service.xml. The test-specific applicationContext-database.xml sits in the "test" directory and contains the following:

<bean id="propertyConfigurer" 
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
	<property name="location"><value>database.properties</value></property> 
</bean> 

<bean id="dataSource" 
    class="org.springframework.jdbc.datasource.DriverManagerDataSource"> 
	<property name="driverClassName"> 
		<value>${hibernate.connection.driver_class}</value> 
	</property> 
	<property name="url"> 
		<value>${hibernate.connection.url}</value> 
	</property> 
	<property name="username"> 
		<value>${hibernate.connection.username}</value> 
	</property> 
	<property name="password"> 
		<value>${hibernate.connection.password}</value> 
	</property> 
</bean>

While the applicationContext-database.xml for the web is simply:

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName"><value>jdbc/appfuse</value></property>
</bean>

To integrate Spring with my web layer (Struts), I just used the ContextLoaderListener in my web.xml file. I didn't see any point in bringing yet another JAR file into the mix.

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Finally, to expose Spring's context to my Struts Actions, I added the following to my BaseAction.java class:

This way, the UserManager implementation can be easier retrieved using:

The best part about the Spring integration in AppFuse is: (IMO) its Hibernate support and how it drastically simplifies my Hibernate DAOs (as if Hibernate wasn't simple enough already). I dig the ability to specify declarative transactions, and this refactoring seems to have reduced the "src" distribution of AppFuse by 2 MB (to 10MB total)! I don't know where this came from since the Spring JAR is almost 1 MB. The appfuse.war is about 500 KB larger, but I can live with that.

Of course, all of this has been checked into CVS if you'd like to take a look.

How much CPU Power does a Java/Tomcat app need?

I tried posting the following to the tomcat-user list, but after not seeing it show up for 2 days, I'll just try it here.
----

I have developed a webapp that uses basic open source stuff (struts, hibernate,
etc.).  I've been developing/testing it on the following platforms - where it
works fine and runs lickedy-split:

OS X 10.3, 1.33 GHz, 1 GB RAM
Windows XP, 2.6 GHz, 1.5 GB RAM
Windows 2000 Server, 1 GHz, 512 MB RAM
Windows 2000 Server, 1.5 GHz, 256 MB RAM

All of these are running Tomcat 4.1.29 or 4.1.12.  I recently tried to deploy
it to the "test web server" (Windows 2000 Server) at my client and it runs 
dreadfully slow.  It takes almost 30 seconds to load a page.  The main difference
is that the test web server has a 667 MHz CPU.  It has 512 MB RAM, and we 
upgraded it to 1 GB, but that didn't help at all.  

I've recommended we get a faster CPU for the test web server, but I wanted to
confirm that this could be the source of the problem.  On this server, and the
1.5 GHz/256 MB RAM machine, IIS is integrated with Tomcat.  All machines are
running JDK 1.4.0 or above.

Any help is appreciated.

ActionForms: Struts' bastard child

Folks that rag on Struts seem to point to ActionForms as one of its major design flaws. I've been slightly frustrated with ActionForms this week, but overall, I think they're a good thing. It's possible my ActionForm affection is misguided. The major reasons I like them is because I believe they allow me to do stuff that is not possible in other web frameworks. I definitely could be wrong though, so I'm hoping the other framework authors/users will speak up and say "My framework does that!" Specifically, I'm talking to the WebWork, Tapestry, JSF and Spring folks.

I do wish that I could throw my POJOs up to my UI, so I hope the following things are possible with the WTJS frameworks. It would simplify things if I didn't need to transform POJOs -> ActionForms (particularly with Hibernate).

• Validation and re-displaying the user's entered values. I love Struts' Validator. It's great how I can generate the validation.xml file with XDoclet and have a "required" struts.validator tag right next to a hibernate not-null="true" tag. Two questions:
  
  1. Can any of the WTJS frameworks re-display the user's entered values? Specifically, back into the input fields where the user entered them? I think this is important for useability.
  
  2. Do any of them have the ability to generate client and server-side validation, or at least declaratively write it in XML?
  
  I'd love to find a way to hack the Validator to allow you to define validation rules for a POJO and then use an Interceptor to validate it. I don't like how Spring requires you to write YAJC (Yet Another Java Class) to do validation.
• Handling checkboxes. The basic reason for the reset() method in ActionForms is to handle checkboxes. Since unchecked checkboxes don't send a value - there needs to be a way to set a boolean back to null. I'm sure all of the WTJS frameworks support checkbox handling, I just want to make sure - and frankly - I'd like to learn a little more about how each framework handles it.

I guess there's only two reasons I like ActionForms - the major one being the ability to specify (and generate) my client and server-side validation in XML. If I don't find this same slick feature in the other frameworks, I might have to do a bit of hacking to do the Interceptor with Validator thing - but hopefully I won't need to go there.