You might want to check out how the Servlet API version 2.2 spec (currently
available to the public in draft form) deals with several of the issues you've
raised below. In addition, I will embed a couple of additional remarks. The
spec is available at JavaSoft's web site.
http://java.sun.com/products/servlet
Cezar Totth wrote:
> Hi,
>
> On Wed, 11 Aug 1999, Alvaro Fuentes wrote:
>
> > We are developing a group of servlets that need to share some info
> > stored in a session. The first servlet creates the session and the other
> > ones retrieve the info from that session. The problem is that those
> > servlets which call
> > req.getSession(false) seem to behave randomly: sometimes they get the
> > session, sometimes they just return null. I think this is because of
> > servlet-reloading when compiling: if we delete ALL servlets (.class),
> > then compile and call servlets, there's no problem. But if we
> > individually compile one servlet, this will not get the session info
> > correctly.
> > Is it possible?
> > Any other possible cause?
> > We're using JRun and Netscape Server.
> >
> > Thanks
>
> This message is also a in attention for the API designers at
> servletapi-feedback@
>
Be sure you submit your comments to this EMAIL address directly, if you haven't
done so. Doing so will ensure that your comments get reviewed and analyzed as
part of the spec development process -- discussions on the SERVLET-INTEREST
mailing list should be primarily focused on helping users with the current
versions of the API.
>
> I would like the possibility to tell the servlet engine that one servlet
> or a group of servlets (an webapp) needs a session to be already created
> and confirmed by the browser, *before* any doGet() or doPost() within
> these specific servlets is called.
>
There is no possibility in the HTTP protocol for communication between the
servlet engine and the client browser *except* for request handling.
Therefore, it is not feasible to "confirm" creation of a session prior to the
first request.
What is feasible, however, is delegating user login checking to the servlet
container (the 2.2 term for the servlet engine), in the same way that you
delegate username checking for protected sets of HTML pages to your web
server. The spec identifies a number of approaches that can be used, including
Basic Authentication (which is exactly what a web server does, popping up the
username/password box) and declaring a custom login form if the user has not
yet authenticated.
>
> Such a feature would save a lot of server-specific programming, from the
> application developer. (check within all servlets if there is a session ,
> if not, redirect to a login servlet or what, but what should I do when
> user accessed another servlet before, and so on..)
>
If you use a servlet container that supports the authentiation service as
described above, the servlet engine will take care of asking for user
authentication for you. What you receive is the identity of the authenticated
user, through the
HttpServletRequest.getRemoteUser()
method. How the authentication takes place, and the mechanisms for identifying
valid users, will be features of particular servlet container implementations.
>
> Such servlets can be marked either by servlet developers through empty
> interfaces (like an RequiresSessionModel interface ) or by deployers
> through configuration parameters in servlet engines (a "NeedsSession"
> flag, similar to "LoadOnStartup" flags used in some servlet engines).
>
Rather than marking the individual servlets, in a 2.2-based web application you
use application-level "declarative security". For example, you can declare
that access to the URI path "/admin/*" (relative to your application) requires
the caller to have a role named "manager". If the user cannot authenticate
themselves to the container with a username/password (or whatever) that
includes that specific role, they are denied access to these resources.
If you wish, you can also check for whether the user has a particular role, in
order to make some dynamic decision. For example, you might add a menu option
to the page you are generating if this user is a manager:
out.println("<h1>Main Menu</h1>");
out.println("<ul>");
out.println("<li><a href="/catalog.jsp">Catalog</a>");
out.println("<li><a href="/order.html">Order Form</a>");
if (request.isRemoteUserInRole("manager"))
out.println("<li><a href="/admin/index.html">Administration
Screens</a>");
out.println("</ul>");
How the servlet container maps roles to users is, again, a feature of that
particular container and not mandated by the servlet API.
The bottom line is that you can get completely out of the session management
and login business, and concentrate on writing the application itself.
>
> Other specific servlets also would be nice to have: Those that tell the
> servlet engine about how sessions should be created -
> "SessionCreateServlet":
> these create sessions and eventually authenticate users, within
> an web application's boundaries.
>
Not needed if you're relying on the servlet container to deal with all of this
for you.
>
> Developers should not need to check login conditions and redirect to
> such servlets in all other servlets they write.
> It would be cleaner if no such specific treatments were needed within
> web applications, and being able to tell the servlet engine that
> the same servlet (login servlet) must be called for any request
> within an application, if no session is opened.
>
Agreed.
The two most common cases of handling authentication will probably be:
* Basic Authentication, where the client browser pops up a username/password
dialog box just like it does for protected static pages.
* Application-defined form (named in the deployment descriptor for the app)
that contains username and password fields with specified field names).
This allows you to control the look and feel of the login screen for your
app,
but you still don't have to deal with the authentication part -- the
container
does that for you.
> In general server-side service developer should be able to add
> capabilities to existing servlet engines - custom authentication
> is a good example.
> Even more, such a service should enable him even to take control on
> what some standard API calls should retorn, like telling the
> engine "ask me what you must return when you-re required to tell the
> getRemoteUser() "
>
We've seen above how the 2.2 spec deals with authentication. You also get to
declare what pages to show for particular HTTP errors or Java exception types,
and many other bells and whistles -- see Chapter 13 of the spec for the legal
options in the deployment descriptor plus a few examples.
The other suggestions you've made (modifying the values that some API calls
should return) are value-added features of a particular implementation of the
spec, not of the spec itself. Note, however, that if you take advantage of
something like this to return values that violate the spec's requirements, any
servlet you write that depends on these violations will no longer be portable.
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
