Craig:

First, thanks for your comments, they are vey useful.

Second, I've two questions in relation to the solution you propose for
session security.

-Does the creation of a new bean for every session impacts on performance?
-Do you think is a good idea to rely on this solution for keeping user
information in the session?



Thanks in advance,

Juan Gargiulo





>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
>

===========================================================================
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

Reply via email to