Hi,
I always have to remember to hit reply all instead of reply so I'm with
you on this one, Craig ;). I also agree with Brian, I find most of your
posts to be very useful and clear so thanks.
Now back to the point, regarding the topic of restricting access to the
JSP/servlet applications I follow and approach which works just great
for our apps. Instead of including a scriplet or piece of code in every
JSP/servlet that belongs to our application, I developed a little
flexible framework because I wanted this to be "simple" from the
developers perspective so let's explain it with a example:
1 .- You first divide your logical application into "domains"
Accessing data from user X can be a domain, from user Y another domain
Accessing administration and monitoring data can be another domain
Domains must be independent (they can't cross each other's boundaries)
2 .- Optionally, you might define which operations can be performed on a
domain
3 .- Define the users your application is going to have
4 .- Define which users can do which operation on each domain
5 .- With that information, you create a class that I call SecurityModel
extending
from a basic abstract class that the framework provides.
6 .- Then you can create a servlet or a JSP extending from basic classes
and providing the information necessary for the security framework to
protect it. That means:
.- Change the extends of your servlet or use the extends directive in
your JSP so you extend the basic secured class.
.- Implement three methods to return:
Which SecurityModel are you using ( see point 5)
Which domain does this servlet/JSP belongs to (see point 1)
Which operation is this servlet executing (see point 2)
Note: Last two can be decided on runtime depending on the request.
7 .- That's all, after that, the security framework will use the
information you provide with methods defined in point 6 and the
information you provide with the security model defined in point 5 to
deny/allow access to your individual JSP/servlets and it's decided in
runtime so you can have a servlet/JSP that decides which user to allow
or not, depending on the parameters of the request.
I had an application consisting on a set of around 10 servlets, 20 JSP
pages and a protected it in 30 minutes, the changes to the code where
minimum as I used inheritance where the values where the same for all
JSP/servlets. This servlets/JSP upload/download files, get and update
data from a database,... I'm quite happy with it and I'm looking forward
to protecting other applications in our organization.
At the moment the framework uses http authentication instead of sessions
to authenticate users, even though we are working on allowing both
systems but you still can use sessions for other purposes, of course.
I was writing a paper about it as I find it quite interesting and I was
also planing to ask my boss to allow me to release this thing as
OpenSource but I wanted first to have some documentation and sample
applications.
After reading what Craig said about servlet API 2.2, I wonder if this is
wasted time or will we be able to merge this new features with our
framework. I had a look at how EJB spec was approaching security and
even though it was close, I didn't like the statically specifying
security in deploy time and letting the server specify how
users/roles(domains) are specified, I send a suggestion to the spec,
suggesting runtime and a basic security model could be good but I got no
answer so...
Last, I'd like to apologize for this long email to those that don't find
it interesting enough ;)
I'd really appreciate comments on the topic.
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
"Craig R. McClanahan" wrote:
>
> The blankety-blank reply to address on this list still defaults to only the
> original sender ....
>
> "Craig R. McClanahan" wrote:
>
> > Brien Voorhees wrote:
> >
> > > I just recently subscribed to this list and have already found several
> > > of your posts to be useful. Thanks for spreading the knowledge, Craig. :)
> > >
> >
> > No problem ... I enjoy it.
> >
> > >
> > > I've always liked separating presentation logic and will likely use a
> > > JSP-Presentation/Servlet-Logic approach as you suggest. One aspect that
> > > seems like it will be a hassle is preventing a user access to restricted
> > > areas of the website. It looks like, for one request, I'll need to verify
> > > that the user making the request is valid in both the servlet and the
> > > JSP(since even jsp's meant to be called only from servlets can be typed in
> > > as a URL) . Has this been your experience? I can derive my servlets from
> > > some sort of ProtectedServlet base class to handle most of the checking
> > > logic but it still seems like a pain. I hate to force all my JSP's to have
> > > user-checking java code embedded in them since the goal is that a
> > > non-programmer web designer can create all the presentation files.
> > >
> >
> > Yah, with current generation stuff this is an issue. I've solved it by
> > requiring the existence of a particular user object in the session, like this:
> >
> > In each JSP page, I have this snippet somewhere at the top:
> > <%
> > LoginBean loginBean = (LoginBean) session.getValue("loginBean");
> > if (loginBean == null) { %>
> > <jsp:forward page="/loginForm.jsp" />
> > <% } %>
> >
> > and the equivalent code in my servlet (I found it convenient to use a single
> > servlet for the app that dispatched to appropriate action procedure based on
> > the requested URL):
> >
> > HttpSession session = request.getSession();
> > LoginBean loginBean = (LoginBean) session.getValue("loginBean");
> > if (loginBean == null) {
> > RequestDispatcher rd =
> > getServletContxt().getRequestDispatcher("/loginForm.jsp");
> > rd.forward(request, response);
> > return;
> > }
> >
> > This way, if the user has never logged on or if their old session timed out
> > (and a new one got created), or they try to jump into the middle of the app,
> > the LoginBean object that I put there on a successful login will be missing.
> > Therefore, I direct them to my username/password form.
> >
> > >
> > > Would taglibs help? I haven't found much documentation on taglibs so far.
> > >
> >
> > The only taglib docs are in the JSP 1.1 spec, and they aren't very helpful to
> > tag developers. I would look more at some of the example tags, to start
> > getting a feel for the kinds of things that will become possible. I expect to
> > see a lot of innovation here, once people start grasping the concepts.
> >
> > You could certainly create a custom tag to embed the login check at the top of
> > the JSP pages more cleanly. However, the servlet API 2.2 also includes new
> > methods on the request (getUserPrincipal and isUserInRole) that allows you to
> > let the servlet container manage logins for you, just like web servers create
> > password-protected subsets of their URL space. I'm looking forward to
> > migrating my apps to this as soon as I can have a server that supports 2.2.
> >
> > That wait should not be too long, since Sun is contributing the source code for
> > the JSWDK to the Jakarta project (http://jakarta.apache.org), as was announced
> > at JavaOne, and the actual contribution should happen real soon now. One of
> > the first things I plan to contribute to the project is some code to manage a
> > little user database, so that you can build apps based on JSWDK that take
> > advantage of these new features.
> >
> > It will be *so* nice to never write another login page again.
> >
> > Good luck!
> >
> > >
> > > Brien Voorhees
> > >
> >
> > Craig
> >
> > >
> > > ----- Original Message -----
> > > From: Craig R. McClanahan <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Tuesday, September 21, 1999 3:59 PM
> > > Subject: Re: Using JSP and Servlets.
> > >
> > > > This is exactly how I write my JSP-based applications.
> > > >
> > > > Basically, any form in my app is submitted to a servlet, which does
> > > whatever functional logic
> > > > is required, assembles the results into beans, stashes them in the request
> > > or session
> > > > (depending on how long the information needs to last), and forwards
> > > control to the JSP page.
> > > > Thus, my servlet might have some code like this:
> > > >
> > > > MyBean myBean = new MyBean(....); // Set up a bean with the answers
> > > > request.setAttribute("myBean", myBean);
> > > > RequestDispatcher rd =
> > > getServletContext().getRequestDispatcher("/nextpage.jsp");
> > > > rd.forward(request, response);
> > > > return;
> > > >
> > > > In the JSP page named "nextpage.jsp", all I have to do to access this bean
> > > is declare it:
> > > >
> > > > <jsp:useBean id="myBean" scope="request" class="MyBean" />
> > > >
> > > >
> > > > Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
