webapp-overview.xtp

RESIN 3.2 最新源码

<p>
The offending java.lang.Throwable describing the error that occurred
is stored in the javax.ServletRequest instance for the client request
using the putAttribute() method, using the name
javax.servlet.jsp.jspException. Names starting with the prefixes java
and javax are reserved by the different specifications of the Java
platform; the javax.servlet prefix is used by the Servlet and JSP
specifications.  If the errorPage attribute of a page directive names
a URL that refers to another JSP, and that JSP indicates that it is an
error page (by setting the page directive's isErrorPage attribute to
true) then the exception implicit scripting language variable of that
page is initialized to the offending Throwable reference.
</p>

</blockquote>

</s2>
</s1> <!-- errors -->


<s1 name="architecture" title="Architecture">

<p>
There are many ways to use the capabilities that are offered by
JSP --  different models apply to different applications.
</p>

<s2 title="Simple JSP">

<p>
The simplest model is to use JSP as an add-on to existing web
pages. At the top of each page is the Java code that is necessary for
the display of the page, and at the bottom is the markup that is to be
output, with appropriate insertion of any dynamically generated
variables.
</p>

<p>
Note the seperation of the different logical parts. It is a very good
idea to keep the presentation section as Java-less as possible. Setup
all of the values in the logic part, and then use only simple
<code>&lt;%= var %&gt;</code> and <code>if</code> statements in the
presentation part.
</p>

<example title="SimpleJSP.jsp - the logic and display code in one page">
&lt;%-- urls --%&gt;

&lt;%
  // store your target urls in String variables
%&gt;

&lt;%-- incoming parameters --%&gt;
&lt;%
  // store form values from the request object in variables
%&gt;

&lt;%-- logic --%&gt;
&lt;%
  // we all make decisions with logic, right?
%&gt;

&lt;%-- presentation --%&gt;

&lt;markup&gt;
  &lt;forthebrowser&gt;
  &lt;/forthebrowser&gt;
&lt;/markup&gt;
</example>

<p>
This seems like a sensible approach. However, imagine that later it is
decided that a different set of HTML is needed for the output if there
is no news available. As well, support of WML output is required. Now
we need to put the display code for 4 different types of output into
one page.  Maybe we need to go to different places as well, for
example an administrator might get a different display page, or we
need to check the users profile to see what is apporiate to display.
This is too much complication to put all in one place.
</p>

<p>
This type of implementation, because of it's limitiations and it's
inability to change without exponentially increasing the complexity,
should be avoided.
</p>

</s2>

<s2 title="Seperating the logic into another JSP">

<p>
To address some of the disadvantages of the Simple JSP method, it is
possible to seperate the `logic' and the `presentation' into two
different JSP files.
</p>

<p>
In this model, instead of a link pointing directly to the page that
does the display, it points to a page that handles the incoming
request.  This 'logic' page contains the Java code that is responsible
for preparing the values that will be used for displaying. It stores
these prepared values as attributes of the <code>request</code> object,
and then <var>forwards</var> to the appropriate display page. The display
page then pulls the information it needs out of the request object and
displays it.
</p>

<example title="SeperateJsp.jsp - The logic JSP that prepares the data for display">

&lt;% 
/** -- incoming parameters -- */
     String strJuiceType = request.getParameter("juiceType");
     String strQuantity = request.getParameter("juiceQuantity");

/** -- logic -- */
Double cost;
String strCost;

here we might do a check to make sure mandatory fields
have values.

Here we might do a database lookup to determine the price, and
set the cost value to the price * quanitity

Now we might format the cost double into 
a two-decimal number and store it in strCost

/** -- set outgoing parameters
    -- forward to display page -- */

/** note that here we put juiceType in as a request
    attribute, even though the display page could get
    it from the request parameters. This helps us keep
    the interface between the logic and the presentation
    cleaner */

request.setAttribute("cost", strCost);
request.setAttribute("juiceType", strJuiceType);
request.setAttribute("quantity", strQuantity);

if (isWML)
    pageContext.forward("SeperateJspPresentationWML.jsp");
else
    pageContext.forward("SeperateJspPresentationHTML.jsp");
%&gt;
</example>

<example title="SeperateJspPresentationHTML.jsp - The JSP that presents the prepared information in HTML format">
&lt;%-- urls --%&gt;

&lt;%-- prepared objects --%&gt;

&lt;%
String cost = (String) request.getAttribute("cost");
String juiceType = (String) request.getAttribute("juiceType");
String quantity = (String) request.getAttribute("quantity");
%&gt;

&lt;%-- presentation --%&gt;

Hey, if you want &lt;%= quantity %&gt; bottles of 
&lt;%= juiceType =&gt; juice, it is going to cost
you $&lt;%= cost %&gt;
</example>

<p>
Here we have introduced a new thing: <code>pageContext.forward</code>.
</p>

</s2>

<s2 title="pageContext.forward">

<p>
The <code>pageContext.forward(String url)</code> forwards the processing to a
different JSP page.  That is, it passes control over to another
page. This page is then executed, inheriting the current request and
response objects. It is important that this is the last thing
that a JSP page does.
</p>

</s2>

<s2 title="Seperating the business logic into beans">

<p>
Even the seperation of all logic into a different JSP can get a bit muddled.
You can seperate the `logic' into two types of logic, business logic
and presentation logic.  
</p>

<p>
Presentation logic is logic that is part of the presentation.
Examples are form validation and formatting of numbers into strings.
</p>

<p>
Business logic is programming that involves your data.  If you can
separate something in your mind from the presentation, it doesn't
depend on the presentation in any way, that's business logic.
Examples are database lookups and shopping cart manipulation.
</p>

<p>
Your application will be cleaner and easier to manage if you put your
business logic in Java classes (beans) which hide the
complexities. You then use these classes in the logic.jsp.
</p>

</s2>

<s2 title="Model 2 (preferred)">

<p>
The final approach discussed here is called the `Model 2' approach. This
approach requires a level of sophistication that is usually not
warranted unless you use a library that supports it, however it is the
cleanest way to implement an application.
</p>

<p>
In this approach there is a special Servlet called a controller
servlet. The controller maps an incoming request to a Java class that
takes care of all of the 'business logic'. This Java class returns a result
that indicates to the controller where it should go next. The controller then
dispatches to the appropriate place.  
</p>

<p>
The flow of a request moves through these `business logic' pieces, finally
ending up at a `view'.  The logic pieces are responsible for examing the
submitted information (such as parameters from forms), managing logical flow,
and preparing objects for the <var>view</var>.  The objects for the view are stored
as attributes of the request (or sometimes, the session).
</p>

<p>
The view is responsible for preparing a response for the user using the
prepared objects now available as request or session objects.  This is where
JSP is often used, it works very well as the view component of a Model 2
architecture.
</p>

<p>
The developer tells the controller what the flow for each request is
by specifying it an external (usually XML) file.
</p>

<p>
This approach is by far the cleanest approach to using Servlets and JSP.  Most
applications of any significant complexity use a Model 2 architecture.  
</p>

</s2>
</s1> <!-- architecture -->



<s1 name="security" title="Security">

<p>
JSP inherits the Servlet security mechanism. Using the two fundamental
concepts of <var>Principals</var> and <var>Roles</var>, JSP provides
declarative and programmatic security.
</p>

<p>
In addition, there is builtin support for various HTTP methods of
login that establish a Principal and it's Roles based on a user login
and password.
</p>

<s2 title="Principals">

<p>
A Principal is established in association with a Session. There is a
one to one correspondence between the two. Usually the Principal is a
user, a real live honest to goodness person sitting at a computer
somewhere and accessing the Web Application.
</p>

<p>
The Application may require that the User go through a login process,
a successful login will establish a Principal, which will have a
certain set of Roles.
</p>

</s2>

<s2 title="Roles">

<p>
Servlet 2.2 Specification states:
</p>

<blockquote>
A role is an abstract logical grouping of users that is defined by the
Application Developer or Assembler.  When the application is deployed,
these roles are mapped by a Deployer to security identities, such as
principals or groups, in the runtime environment.
</blockquote>

<p>
Roles are similar to groups in Unix security.  As an example, you
might have a "member" role for users who have a membership, and an
"admin" role for administrators.  
</p>

<p>
Principals can have more than one role -- a user might be both a
"member" and an "admin".
</p>

</s2>

<s2 title="Declarative Security">

<p>
Servlet 2.2 Specification states:
</p>

<blockquote>
Declarative security refers to the means of expressing an
application's security structure, including roles, access control, and
authentication requirements in a form external to the application. The
deployment descriptor is the primary vehicle for declarative security
in web applications.
</blockquote>

<p>
Basically what this means in real terms is that you can specify
certain paths in web.xml that require certain roles. For example, you
can say that to access any page in the "/accountsetup/" subdirectory,
the user must have a role of "admin".
</p>

</s2>

<s2 title="Programmatic Security">

<p>
Servlet 2.2 Specification states:
</p>

<blockquote>
Programmatic security is used by security aware applications when
declarative security alone is not sufficient to express the security
model of the application. 
</blockquote>

<p>
Programmatic security lets you decide in some Java code what to do,
based on the role that a user has.  For example, you might make a
certain button appear in the button bar only for an "admin" user.
</p>

<deftable title="Programmatic Security API">
<tr><th>Method</th><th>Description</th></tr><tr><td><a href="javadoc|javax.servlet.http.HttpServletRequest|getRemoteUser()">request.getRemoteUser()</a>
return the name of an authenticated user.

</td></tr><tr><td><a href="javadoc|javax.servlet.http.HttpServletRequest|isUserInRole(String)">request.isUserInRole(String role)</a>
</td><td>return true if the current user is in a given security role.

</td></tr><tr><td><a href="javadoc|javax.servlet.http.HttpServletRequest|getUserPrincipal()">request.getUserPrincipal()</a>
</td><td>return the <a href="javadoc|java.security.Principal|"/> associated with the
current user.
</td></tr></deftable>

</s2>

<s2 title="When does Resin require a login?">

<p>
The resources in an Application are by default open to the public, and
do not require a login. As soon as the User attempts to access a
resource that has been declared to require a role in the web.xml,
Resin will insert in the process a login of some kind before
continuing on to the resource that was originally requested.
</p>

<p>
For example, if the "/members/*" area has been declared to require a
"member" role, as soon as the user tries to access anything in
"/members/" Resin will check to see if the user has logged in
yet. If the user has logged in, then the roles for the user are
checked to see if "member" is a role that user can take.  If the user
has not logged in, Resin inserts a login procedure and then
checks the roles.
</p>

</s2>

<s2 title="The login procedure">

<p>
The Servlet Specification details numerous methods for getting user
identification and password information from the user.
</p>

<p>
The example below shows usage of "Form Based Authentication", which
allows you to specify a login page to be sent to the user when needed,
and an error page that will be displayed if the user login fails.
</p>

<p>
The login page should submit a form to the url
<code>j_security_check</code> with the parameters 
<code>j_username</code> and 
<code>j_password</code> set to appropriate values.
</p>

<p>
Resin recognizes the special url <code>j_security_check</code> and
authenticates the username and password.
</p>

</s2>

<s2 title="Lifecycle of a Principal">

<p>
The Servlet authentication associates a <var>principal</var> with a <a href="#session">session</a>.  The principal will only last as long as the
Session; as soon as the Session is gone then the user will no longer be logged
in.
</p>

<p>As a result, invalidation of the Session will also cause a logout:</p>

<example>
session.invalidate();
</example>

<p>You can also cause a logout without invalidating the whole Session. Other
objects in the session will remain available but the principal will be
null:</p>

<example>
session.logout();
</example>

</s2>


<s2 title="Authenticating the User">

<p>
Once the user information is collected, the password must be verified
and the roles determined. Unfortunately, the Servlet specification
does not indicate a standard way for this to occur.
</p>

<p>
What that means is that every Container is likely to do this
differently, and you will have to refer to Container specific
documentation and examples.
</p>

</s2>

<s2 title="Example usage of Security">

<p>
The Resin documentation on <a href="security.xtp">Security</a> includes a
comprehensive discussion, and the <a href="../examples/security-basic/index.xtp">Basic
Security Tutorial</a> is a good starting point as well.
</p>

</s2>
</s1> <!-- security -->


</body>
</document>