Life In Code

Spring Security

2009-10-30T12:55:00.013-04:00

I'm working on a project using the Spring Web MVC framework. I was interested in learning more about Spring Security to have it manage authentication and authorization for me. This way I can avoid having to write a custom form controller to manage authentication, and coming up with some home-grown ACL strategy. I decided to try out the petclinic tutorial. It seemed like after reviewing the information that I would be able to use Spring Security in my project.

So, I repeated the steps of the tutorial on my own project. But I soon found out that the login page being displayed was not a jsp found in the petclinic project. Instead, it is generated by the Spring Security library. This won't do. I need a login page that looks like the rest of my application. So, off to Google I go...

Fortunately, I'm not the first person to have this same issue. Thanks to Peter Mularien for putting together this excellent summary of and expansion on the petclinic tutorial. The one thing I did differently in my project is that I wanted to enforce concurrent session control. This is easily accomplished by adding the following to your security:http configuration:

<concurrent-session-control max-sessions="1" exception-if-maximum-exceeded="true"/>

However, I was experiencing a bad side-effect. Now once my user logged out, they could no longer log back in. After posting a question on Stack Overflow I discovered my own answer. There is another listener required in the deployment descriptor to use session control:

<listener>
<listener-class>org.springframework.security.ui.session.HttpSessionEventPublisher</listener-class>
</listener>

Once again, I'm left with the feeling that Spring is great, but its lack of documentation for what I would consider to be core features is a chronic issue for me. Spring is not for the faint-hearted or easily-frustrated. One must have the intestinal fortitude to dig in and figure things out on their own...and search Google.

Programming Zen

2009-10-04T12:22:00.000-04:00

C = an axe: lots of people use it for lots of basic, but serious jobs.
C++ = a double-bladed axe with a graphite handle and a rubber grip: similar, but fewer people use it, and they feel special having held it in their hands.
Java = one of every kind of axe there has ever been, all lined up neatly in a row.
Python = that old stand-by pair of scissors in your top drawer.

REST Services Supporting XML and JSON Using Zend Framework

2009-09-22T10:43:00.008-04:00

I have been working on a project to build a RESTful Web service to handle provisioning requests for a PHP web application. The developer working on the web app is using Zend Framework web MVC. I wanted to stick with PHP so I could "hand off" the provisioning API once it is done. After doing some research, it seemed that Zend Framework also had good support for what I wanted to accomplish with REST.

I have never used Zend before, and my most recent PHP experience was over three years ago, so I was hoping there would be good examples/tutorials. Fat chance. I found several other blogs that gave an account of their own personal trials (and in a couple of cases, successes), but nothing in the order of "official". To give credit, Chris Danielson's post was my starting point but left quite a bit out that I needed.

First, why if I specified "format=xml" in my URL did the view still get returned as JSON? This was unnerving to say the least. After doing some digging, I found the answer on the Zend Framework Manual. Specifically, the section titled "12.8.4.3.1. Default Contexts Available" mentions that you have to disable automatic JSON serialization. Minor detail? So finally my XML view start working when I ask them to...

Next, how the heck do I access the request body for a POST or PUT request? In Chris Danielson's blog, his example shows the following to get an incoming parameter:
     $this->getRequest()->getParam($paramName)

This only works for the query string though! So again, I did some looking, and found this:
     $this->getRequest()->getRawBody()

Makes sense...but again, would have been great to see an example of this somewhere.   All of the blogs I looked at focused on GET requests...as if POST is never used. :-)

Once I had these issues ironed out, it was just a matter of implementation. But as I got further into development, I saw a pattern forming that seemed ideal for the Framework to handle. It occurred to me that - for each method handler - I was:

Adding an action handler to context switch for XML and JSON
Defining a common document structure for the response (view) to be returned, regardless of context.
Wrapping the view in "resolvable" phtml documents that encode the document in the proper context.

Why is all of this necessary? So I asked the experts: read my proposal for ZF-7825. As of this posting, the proposal is still under development, but my guess is this will show up in some 2.x release of Zend Framework.

Overall I would say that Zend Framework is a good choice if you're starting a new Web service project with PHP. It is under active development by numerous contributors and supports a large number of features out-of-the-box.

You can download the code here.

-aj