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
