seamy photo gallery, securing it (part 2)

The new requirement that I wanted was "photos should be approved before being shown in the main page". For that I needed users with approving privledge or role, therefore it was time to dive in to the seam security part. I used simplest User and Role classes that I could think them and configured them :

<security:jpa-identity-store
user-class="domain.User"
role-class="domain.Role" />

Seam requires that you annotate your user domain and specify your username, password and other fields with annotations. Simplest model mostly from the reference :

public class User {
@Id
@UserPrincipal
private String login;

@UserPassword
private String password;

@ManyToMany(cascade = CascadeType.PERSIST)
@JoinTable(name = "USER_ROLE")
@UserRoles
private Set<Role> roles = new HashSet<Role>();
...
@Entity
public class Role {
@Id
@RoleName
private String name;
...

@Password annotation has the option to hash the data behind the scenes if you wish so. 

The next thing to the is authenticator method.

<security:identity
authenticate-method="#{authenticator.authenticate}" />

@Scope(ScopeType.APPLICATION)
@Name("authenticator")
public class Authenticator {

@In
EntityManager entityManager;

@In
Identity identity;

public boolean authenticate() {
 try {
     User u = (User) entityManager.createQuery(
             "select u from User u where "
                     + "u.login = #{credentials.username} and u.password = #{credentials.password}")
             .getSingleResult();

     CollectionUtils.forAllDo(u.getRoles(), new Closure() {
         public void execute(Object objrole) {
             Role role = (Role) objrole;
             identity.addRole(role.getName());
         }
     });

     return true;
 }
 catch (NoResultException ex) {
     return false;
 }
}

@Create
public void initTestUsers() {
 entityManager.persist(new User("mca", "mca").addRole(new Role("user")));
 entityManager.persist(new User("op", "op").addRole(new Role("admin")));
}

}

Authenticate method returns if the authentication is successfull or not. Credentials component is used to hold username and password of the user trying to login. If the authentication is successfull we also need to add the user roles to identity component. I have also used the @Create annotation so that I could create some test users when the component is created. The login page needs to get the values to credentials compenent and simply call the Identity.login method :

<h:inputText id="txt_username"
       value="#{credentials.username}" ...
<h:inputSecret id="password"
         value="#{credentials.password}" ...
<h:commandButton value="Login" action="#{identity.login}"/>

Up to this value we have done what is needed to authenticate a user. To secure our main page we need to mark it a page which needs login on pages.xml :

<pages login-view-id="/login.xhtml" ...

<page view-id="/photo/index.xhtml" login-required="true">
 <rewrite pattern="/photo/index" />
</page>

Now when a user logs in he will be redirected to the login page specified in the pages tag. When the login is successfull to redirect the user to their original target page you can use the redirect component with the events:

<event type="org.jboss.seam.security.notLoggedIn">
  <action execute="#{redirect.captureCurrentView}" />
</event>

<event type="org.jboss.seam.security.postAuthenticate">
  <action execute="#{redirect.returnToCapturedView}" />
</event>

Will be continued...

Bulldozer coding

Jaroslav Tulach, designer of NetBeans API, defines the bulldozer coding as  instead of designing elegant solutions to problems at hand, you choose to use heavy libraries which are good for manythings in "Practical API Design". Which kind of reminds me of the Developer Jar Ratio that I wrote here.

Up side of the aproach is you are supposedly getting things done more quickly therefore increased productivity.

Apparent downside is that increased system resources needed for the application. The answer to that is buying memmory is cheaper than the developers time.

This approach apperntly works but still I don't think it is acceptable. My personel experience is that while you should use cluster of servers for your application you should also need powerful machines for your developers in order to get the developement time benefit. For example checking the hibernate forums lots of junior developers find out that they needed to extend "permanent heap size" the hard way. Again even with a powerful machine and hot deployment enabled server you will be restarting your machine a lot which is the faster the better. If you are using an api like hibernate which generates classes to do their trick and jvm with a permanent heap space, the more you restart your machine the more classes will be left in your memmory which means buy more RAM. The funny thing is as this is a developement problem it can be thoughted to be ignored.

more notes on seam

Here is more tips on seam;

• I found out that blog example I wrote about has a little bit of history behind it. Apparently it was developed in response to a blog of Simon Brown. He publishes a set of blogger application requirements to compare web frameworks. Although Gavin argues that a blogger application hardly JEE, he still developes the example. Read more on it here http://relation.to/Bloggers/ComparingWebFrameworksSeam .
• To validate against hibernate validators with JSF only thing you have to do is wrap the components with the "s:validateAll" tag. So if we have a name field in our page like;

  <s:validateAll>
  <h:inputText id="txt_name" value="#{newPhoto.name}" required="true" />
  </s:validateAll>
  

  Which is annotated like;

  @Length(max = 20)
  String name;
  

  "s:validateAll" tag will make sure nothing more than 20 characthers will pass and if tries to, a jsf error message will be raised. We could do all the basic validations but still not the required validation because, JSF does not call the validators if there is no value present...
• Really liked the jboss el. You can even use it with ejb-ql's. Which is useful with standard seam components like the credentials component. This example is to check the credentials of a user: 

  User u = (User) entityManager.createQuery(
  "select u from User u where "
  + "u.login = #{credentials.username} and u.password = #{credentials.password}")
  .getSingleResult();
  

  A little DSL and we don't have to do more method chaining to pass the parameters. You can also use the EL with some  security annotations and possibly on more places...
• It's not beans with seam. They call it components. And you can configure, add and remove them through components.xml . You can inject variables to your components with out the scope limit. And components can outject variables.
• To configure components seam people chose to make a API of annotations instead of defining interfaces like the spring api has. I am not sure if the spring api has something new but this is what you used do if you needed a method to run after a bean has been created;

  public class SomeBean implements InitializingBean, ... {
  ...
   public void afterPropertiesSet() throws Exception {
  ...
  

  That is you have to implement the InitializingBean interface. On seam you have to annotate a method with the @Create annotation:

  @Create
  public void initTestUsers() {
  ...
  

  I personally liked the annotation approach better in a language perspective, but I guess its harder to implement and will depend on reflection api, so will be slower.
• Another thing was my toy app was not working yesterday. It turned out that it could not access the dtd's in xml definitions because jboss was on maintainnance so I deleted them from xml's...

little restfull photo gallery example, with seam, which seams fine

I have decided it was time to check out the seam framework since many of my friends gave it a thumbs up. Starting with the blog example that comes with the package I have built a little restfull image gallery. Which looked liked this;
I started with a simple Photo domain object which has name as the id, and the data byte array as the photo file:

@Entity
@Name("newPhoto")
@Scope(ScopeType.SESSION)
public class Photo {
@Id
String name;
byte[] data;
...
}

Whats seamy here is the @Name and the @Scope annotations. @Name annotation declares named beans of the type. In this case I created one to use to hold the user submitted information. @Scope annotation declares the scope of the bean in this case I will use one bean for every session.

Then the action methods to persist and retrieve the photos:

@Name("pholog")
public class PhotoService {
@In
private EntityManager entityManager;
public List<Photo> getFrontPagePhotos() {
...
public byte[] getFoto(String fotoId) {
...
public void createNewPhoto(Photo p) {
if (p.getData() != null) {
try {
entityManager.persist(p);
}
catch (PersistenceException pe) {
FacesMessages.instance().add("Data exists!");
}
}
else {
FacesMessages.instance().add("File is required!");
}
}
}

The @In annotation injects other beans to our new bean. On the createNewPhoto method I do some validations and add validation errors if needed which I suppose a declarative syntax might exist that I don't know about.

On the view side seams comes with some extra tags that standard JSF does not have like the, fileUpload tag, or a better integrated graphicImage compenent. Nevertheless I had to add the richfaces package since I didn't like the way the standard datatable looks and behaves.

My form to upload a Photo:

    <h:form enctype="multipart/form-data">
<span class="errors"><h:messages /></span>
<h:panelGrid columns="2">
<h:outputLabel value="Name" for="txt_name" />
<h:inputText id="txt_name" value="#{newPhoto.name}" required="true"
requiredMessage="Name is required!" />
<h:outputLabel value="File" for="flu_dosya" />
<s:fileUpload id="flu_dosya" data="#{newPhoto.data}" />
</h:panelGrid>
<h:commandButton action="#{pholog.createNewPhoto(newPhoto)}"
value="Create" />
</h:form>

Tricky thing about the fileUpload was that you have to mark your form as "multipart/form-data" otherwise nothing gets uploaded. I am not sure if this is just a seam thing or a JSF spec thing. Another important feature here is #{pholog.createNewPhoto(newPhoto)} el expression which glues the domain and the action beans we have declared. I used to do something similiar using ognl expressions now it comes out of the box. 

Part that displays the gallery:

    <rich:dataGrid value="#{pholog.frontPagePhotos}" var="foto" columns="3"
elements="9">
<h:column>
 <s:div>
     <s:link id="lnk_foto" view="/photo/photo.xhtml" propagation="none">
         <f:param name="fotoId" value="#{foto.name}" />
         <s:graphicImage id="imaj" value="#{foto.data}"
             style="border: 1px solid black;" lt="image could not be found">
             <s:transformImageSize width="100" maintainRatio="true" />
         </s:graphicImage>
     </s:link>
 </s:div>

I used the rich:dataGrid component which gives me nice 3x9 grid to display my images. seams graphicImage component converts the photo byte [] to a resource link which is served. In order it to work you have to add the Seam Resource Servlet to your web.xml;

    <servlet>
  <servlet-name>Seam Resource Servlet</servlet-name>
  <servlet-class>
      org.jboss.seam.servlet.SeamResourceServlet
  </servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>Seam Resource Servlet</servlet-name>
  <url-pattern>/seam/resource/*</url-pattern>
</servlet-mapping>

The s:link component links the thumbnail to photo.xml page where the image will be displayed with a restful url. My photo.xhtml is simply like;

<f:view>
<s:graphicImage id="imaj" value="#{pholog.getFoto(fotoId)}"
    style="border: 1px solid black;" lt="image could not be found">
</s:graphicImage>
</f:view>

It has a graphicImage component with no transformations and gets the foto with the fotoId parameter. In order this to work and have urls like /examplegallery/photo/photo/yoda to display the image with the name yoda you have to make one last configuration in the pages.xml file;

    <page view-id="/photo/photo.xhtml">
      <rewrite pattern="/photo/photo/{fotoId}" />
      <param name="fotoId" value="{fotoId}" />
  </page>

Here we are creating meaningful urls that could be bookmarked. In this case its like the page, photo, whit the foto name (photo id). And our page used the id (name) to retrieve and serve the image.

And for the last, things that I am curious about seam;

• pages.xml file had to be seperate files since one file could easily go up to thounds of lines in a real project which won't be manageable. Or there might be a way that dumps the use of that xml file.
• I am not entirely sure what the component.xml file does...
• There could be a easier and better way to handle validations and display JSF exception that includes handling hibernate exceptions, validations.
• Got to check out the seams conversation and navigation features.
• Do a example with the bijection feature.

Those are my first impressions about seam I have added most of the code I added to the blog example here. So rest of the configuration is there.

Developer JAR Ratio Hypothesis

Ever felt like you are dealing with 3rd party jars and library's more than you have to ? They may make things easy but they come with a lot to know and nasty bugs that you have to track down. I believe making the decision of using a 3rd party jar, or building the solution yourself is not an easy one. 

On the one side of the problem is you don't want to reinvent the wheel and use the established solutions. On the other hand those libraries comes with lots of features that you don't really need, they may be well tested but still you will probably run into some hard to tackle problems and bugs, for the last the development team would have to learn to use the library properly. 

Adding a new jar to the classpath should be carefully thought based on, how much you already know the library, will it be a overkill to add the library or are you shooting birds with rockets, make sure you are not just using because it’s a popular acronym, and what will it really cost me to develop right to the point solution. 

And at least my little hypothesis "while the developer per jars goes to zero the more complex and unmanageable becomes your project".