Overview

Here is a very quick rundown on what each term in the MVC pattern means:

• Model – this represents the business rules that you are trying to code. Another way of looking at it is that the Model is what does all the work. It is what performs any and all transformations on the data that your application is required to handle.
• View – the view represents what the user sees and it is responsible for the collection and display of data for and from the model.
• Controller – the controller is what ties everything together, it is the link between the view and the model.

One way of looking at MVC is that the user views a web page which displays and/or collects data. When the user submits this page, it is submitted to the controller which knows what to do with the data collected by that page. The controller does not know how to transform the data, but it knows which part of the model contains this knowledge and passes the data onto the model. The model then transforms the data. The controller, based on whether the transformation was a success or not, determines which part of the view to call and returns to that view a piece of the model in order for the view to display more data to the user. (Did you follow all of that?).

An Example

Here is a quick example: A user login page.

1. The user sees the login page with a form that contains a field for the username and the password.
2. The user fills in this data and submits it to the User controller with an action of login.
3. The User controller knows to pass this information on to the loginDAO which attempts to verify that user against the database.
4. If the user exists in the data, the model instantiates a User object and returns that object to the controller.
5. The controller then tells Tomcat to load the homepage and sends the user object to the resulting jsp page.
6. The view then shows a nice little “Welcome back Sue” message for the user to see. The name in the message comes from the user object.
7. If the user does not exist in the database, the model returns an error and the controller instantiates the error page with an appropriate message to the user.

The general idea behind the MVC pattern is to abstract and remove as many dependencies as possible from between the layers. If done correctly, the entire web interface could be removed and a Swing ui could be put in its place with no code modifications needed on the part of the model. You may need to code up a few different controllers, but the model should not have to change. Likewise, you should be able to replace the entire model without having to change the view. This is accomplished because the point of dependency is the controller which sits in the middle.

I have listed a few links below for more information.

Reference

• Head First Servlets and JSP: Passing the Sun Certified Web Component Developer Exam (SCWCD) — this is an excellent book that discusses the MVC pattern and how to implement it using JSPs and Servlets.
• Model-view-controller — Wikipedia entry on MVC
• Understanding JavaServer Pages Model 2 architecture — a JavaWorld article from a few years ago that discusses the MVC model 2 pattern
• Struts — Struts is probably the most popular MVC implementation for Java web development
• Core J2EE Patterns – Dispatcher View — a pattern in Sun’s Core J2EE Patterns that allows you to implement the MVC design pattern

Layered Architecture

Layered Architecture is a term that you hear all the time in the world of Java, but what does it mean? In a nutshell, it is about putting code into layers—one layer for all the presentation code, one layer for the persistence code, one layer for the business rules, one layer for the object model, one layer for services, and other layers. It is a way of organizing your code that carries several benefits when done correctly.

Organized Code

Why can’t I just put all my code in the same place? This works well for a few classes, but once you have a few more classes, and then a few more, and a few 100 more, you need to organize those classes somehow. Layers is one way to do this. In Java, teh word layers translates to packages. So, in order to create these layers, you simply put your code into different packages. As an example, you could create a package called com.foo.presentation and put all your presentation code into it. Here is an example list of packages for a new application:

• com.foo.presentation
• com.foo.business
• com.foo.persistence
• com.foo.objectmodel
• com.foo.services

Abstraction

The better reason for organizing your code into layers is for abstraction and encapsulation. This allows you to keep dependencies at a minimum and allows you join the layers through abstraction instead of through direct instantiation. Basically this means that you persistence layer can exist independently of any of the layers above. And the layers above call the code in the persistence layer through an interface instead of through concrete classes. In a component diagram, this means that you would have dependency arrows going down through the layers instead of both ways. Below is a diagram showing what I mean.

As you can see from the diagram, all the arrows either travel down through the layers or to the two side layers. These downward arrows represent the direction of dependencies through the application. The advantage of this is that if I build an application correctly, I should be able to swap out any of the layers and replace with entirely different code without breaking any of the other layers. So for example, if I am using Hibernate as my persistence layer, if I set up the correct interfaces I should be able to swap in something like Top Link or iBatis and DAOs and the entire application should continue to work. This is the power that a layered architecture gives you.

This is a very simple introduction to the concept of layered architecture, there are entire books that can be written on the subject. The best of which is probably Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman. This is one of those books that every software developer should read. It introduces not only Object-Oriented analysis and design using UML, but also design patterns and speaks at length about layered architectures in software development.

Feel free to leave comments on what I have written. If you have questions or issues with/about what I have written, please let me know through the comments section.

Resources and Links

• MVC and Layered Architectures in Java
• Model-View-Controller — and implementation of a layered architecture

*hosts.allow and hosts.deny*
This is probably your first line of defense. These two files control who can gain access to your computer in the first place. They do this by restricting the people according to their IP address, IP range, or domain name. In order for them to work correctly, you really need to use them both together. Block everyone using the hosts.deny file and then only let those people in that you trust using the hosts.allow file. Check the man pages for both files, but here are two simple examples to show you how the files work. If you wanted to block everyone from accessing your computer except for those on your internal network, this is how the files would be setup:

hosts.deny

ALL: ALL

hosts.allow

ALL: LOCAL, 192.168.0.

You will notice that for the internal network IP, I did not specify an entire address. I left the last digit off. This allows you to specify a block of addresses. In this case, anyone trying to access the computer whose IP address begins with 192.168.0 will be allowed. Basically, this allows anyone on your internal network to gain access (assuming that you network uses 192.168.0).

In addition, you can also specify domains and/or outside IP addresses and IP address ranges. For instance, if the company that you work for has a domain called www.foo.com, then you could specify that in the hosts.allow file. This would allow you to connect from work. Or, if your company only uses IP addresses, then you could put that in as well. Here is what the file could look like:

ALL: LOCAL, 192.168.0.
ALL: .foo.com, 123.456.789.

This establishes where you can connect to your computer from. But what if you don’t want to restrict the entire world from connecting? Then the next best thing is to restrict how they can connect. For this, we secure SSH.

*Securing SSH*
For this, you will need to edit your sshd_config file. This is usually located in /etc/ssh/sshd_config. There are two key areas that you will want to change. The first will look like this:

# Authentication:
#LoginGraceTime 120
#PermitRootLogin no
#StrictModes yes

What you want to do here is to uncomment the PermitRootLogin. This will prevent anyone from logging onto your computer over ssh as root. This means that in order to gain root access, someone will have to first login using a regular user account and then su to root.

The second thing you can do to secure SSH is to which users/groups can login and which can not. To do this, you use four commands – AllowGroups, AllowUsers, DenyGroups, DenyUsers. You use the AllowGroups and AllowUsers to explicitly state which users and which groups can log in through SSH and you use the DenyGroups and DenyUsers to deny all other accounts from logging in. And these you can place at the end of your sshd_config file. An example might look like this:

AllowGroups users foo
AllowUsers foo
DenyGroups root bin postrges mysql nobody apache
DenyUsers root bin postgres mysql nobody apache

And that is all that there is to it. Listed above are two simple tricks to securing a Linux computer. However, they are not guaranteed to make your computer completely cracker proof. There are many more things that you will need to do in order to completely secure your computer against attack (proper firewall, secure all open ports, use secure passwords, etc). But the above is a very good start and should be a part of every linux users toolbox when it comes to securing a computer on the Internet.

Once you have your groups, you need to decide which parts of your site can be access by each group. Obviously, an administrator can access everything while an author can only submit stories. While an editor can access an authors submitted story before it is published. Each part of your site needs to be assigned to a Group. Just remember this for now, we will discuss how to do it a little later. First, let’s discuss how to set up our groups and users in a database.

If you remember, the idea behind this is to separate the users from the groups that they belong to. This is done by creating three tables in a database. One table to hold the users, one table to hold the groups, and the last table to assign a user to a group. Here are what the tables might look like:

User
  +--------+----------+----------+
  | userID | username | password |
  +--------+----------+----------+
  | 1      | foo      | bar      |
  +--------+----------+----------+

Groups
  +---------+----------+-------------+
  | groupID | group    | description |
  +---------+----------+-------------+
  | 1       | admin    |             |
  | 2       | editor   |             |
  | 3       | author   |             |
  +---------+----------+-------------+

User_Groups
  +--------+-------+
  | userID | group |
  +--------+-------+
  | 1      | 2     |
  | 1      | 3     |
  +--------+-------+

As you can see from the tables above, this setup allows a user to belong to more than one group. This is what allows a user to progress through positions on the site. A user can start as an author and then move up to an editor while still retaining all the abilities of being an author. In addition, it allow you to isolate a user as an editor. This would mean, in our little example, that that user could access and edit stories, but they would not be able to submit any of their own. For complicated sites, this can be an advantage.

Now that you have your users and groups all setup in the database, how do you translate this to the rest of your site?

First, you need to have your users login to your website. When they login, you check their username and password against the database. If they are a valid user, you then retrieve the list of groups that they belong to. This is the important part. You need to place that list of groups into a session variable that will be accessible from every page on your site. For security reasons, you don’t really want to store this kind of information in a cookie as it is too accessible to a malicious user. Therefore, to implement this, you need to pick a language that supports user sessions.

Now that you have the list of groups a user belongs to, how do you enforce this against pages on your site? There are many different ways of doing this depending on how your site is setup and what kind of information you need to restrict. I am simply going to illustrate this by making it so that all that needs to be restricted is access to individual pages.

The easiest way to enforce your groups is to assign each page (or group of pages, depending on their functionality) to a group. So for the author, all the pages that work together to allow an author to submit a story would be assigned to the author group. On a praticle level, this can be as simple as setting a variable at the top of your page. This is how you would do this in php:

< %php $group = "author" %>

Once the variable is set, you need to validate your user against that group. How you do this will depend on how you implement your list of groups that a user belongs to. Different languages will have different ways of handling lists and searching for elements in a list. But basically, all you want to see is if the value of the group variable matches an element in the users list of groups. If it does, the user belongs to the same group as the page and is able to access that page. If a match can not be found, then you can redirect the user to an error page or back to the homepage.

This is the most robust method of authentication and authorization that I have come across so far. And it is fairly easy to implement. So if you are looking for a method of restricting different parts of your site to different kinds of users, give this a try. You will quickly see the advantages that it holds.