Chapter 4: Authorization

The story

By this time, Joey considers his task done. What else could one want to do? We've looked at Model, View and Controller, we added logic, and changed existing logic. We saw some Ajax on the process. There's nothing else to do. Right?

One big difference between a real web application and a toy is that the professional solution handles authorization constraints. Simple access rights make a world of difference. For example, a blog toy might get away with "all posts are public", but a real blog software must make sure that only the authors can post and only published posts can be read by everyone.

A real event tracking system like Joey is writing must also have access rights. He wants people to be able to add events on their own page, but not on everybody else's page. Let's give him a hand.

During the last chapters, you noticed how we skipped authorization constantly. We needed to skip it because MUM forces you to consider authorization when developing the business logic, which we consider a feature. Joey, like most developers, rarely thinks about authorization as part of the application design, but that's where it truly belongs. If you think about it soon enough, you might even come up with better data models.

But it must be easy to implement or people won't do it. Enter Talos, our expressive authorization engine that allows you to write human-readable code like this authorization check from "UpdateUser":

public boolean authorize(String subject) {
  return talos.withSubjects(subject)
      .andObject("Object:" + user.getId())
      .isAllowed("modify");
}

Please send us comments, questions, criticism:

Name: Email: Homepage: Comment:

Please send us comments, questions, criticism!