Because every time you access your servlet, you need to check if the user is
logged in!
--Olu E.
> -----Original Message-----
> From: David Hildebrandt [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, December 16, 1999 8:01 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [design] set of servlets that require login
>
> Why subclass from LoginServlet in the first place?
>
> Why not simply use LoginServlet (or an EJB) in the application servlet?
>
> The act of login is well-defined but short-lived. I have trouble seeing
> how
> the concept of login could be a prevailing design idea. However, I have
> not
> followed the discussion too closely.
>
> >>>>>
>
> if (LoginFacility.isValid(userID, password))
> {
> User user = new User(userID);
> session.putValue("User", user);
> }
> else
> {
> new LoginFacility.showFailedLoginPage(request, response, userID);
> }
>
>
> (I do not know how two servlets communicate, so please bear with me).
>
> The relationship between LoginFacility and servlet seems so fleeting --
> definitely little time for any emotional attachment to form.
>
> -----Original Message-----
> From: Danny Rubis [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 16, 1999 5:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [design] set of servlets that require login
>
>
> Hey!
>
> I must say that I am very interested in your LoginServlet design.
>
> You say >>>>>>>
> I'm turning all requests into POSTs, but that's kind of
> "rude", as some sub-class servlets may behave differently in the case of
> POST than GET. (I can't think of a reason why; generally, I either
> implement only POST b/c the servlet's action is not idempotent, or I
> implement doGet and then make doPost simply call doGet. But LoginServlet
> will be sub-classed by other developers, and I can't constrain them this
> way.)
> >>>>>>>
>
> I am one that has implemented POST and GET differently in some cases. I
> would hate to give this up.
>
> Sans adieu,
> Danny Rubis
>
> "L. Turetsky" wrote:
>
> > Hi all,
> >
> > I've looked thru the archives (and have been a list subscriber for a few
> > months) and haven't seen a discussion on this yet, so here goes...
> >
> > I'm working out what I think is a wise/clever design for a servlet-based
> > login system.
> >
> > I've been tasked with writing an extensible membership area for a
> website.
> > The idea is that people have to login to access certain pages, and some
> of
> > those pages may include dynamic data specific to the logged-in user
> (e.g.,
> > what books they've bought in the past). Pretty standard fare, IMO.
> >
> > I've written two such servlet-based systems in the past, both with the
> > following design pattern:
> > All login-required servlets sub-class from an abstract class called
> > LoginServlet, whose service() method does the following:
> > if login info (name&password) is in request, check the info
> > if valid, store a Login object in Session & call
> super.service() (which
> > calls doGet/doPost)
> > else, show a login screen
> > else if user is already logged in (i.e., there is a Login object
> in the
> > Session), call super.service() (which calls doGet/doPost)
> > else, show a login screen
> >
> > The nice thing about sub-classing from LoginServlet is that it allows
> the
> > specific servlets (and their authors) to concentrate only on their task
> w/o
> > any need for understanding how login is done (the basic idea behind
> > inheritance in general). All they know is that the login info is
> available
> > from the Session's Login object, accessible via the static method
> > Login.getLogin(HttpServletRequest).
> >
> > When the login screen is presented, all the parameter fields in the
> request
> > (except name/password) are encoded in the login form as INPUT
> > TYPE="HIDDEN", and the FORM ACTION= HttpServletRequest.getRequestURI()
> > (i.e., the servlet they were trying to access, since it subclasses
> > LoginServlet). That way, once the login is authenticated, the user's
> data
> > is passed to the servlet s/he was trying to access.
> > This is useful in the case of a user's login session expiring while
> filling
> > out a long form, so they don't have to re-enter all the data. For
> example,
> > imagine that you login to a site, start filling out a huge form during
> > which time your login expires. When you submit, you're asked to login
> > again. In this design, as soon as you login the data you entered into
> the
> > form is passed on and you're back on the path you were travelling.
> >
> > OK, so what's the problem?
> >
> > Well, to keep the request un-changed, the login page's FORM METHOD=
> should
> > be HttpServletRequest.getMethod(). However, in the case of GET requests,
> > the resulting URL contains the username and password (e.g.,
> >
> http://www.myserver.com/servlet/SubClassOfLoginServlet?userName=lenny&pass
> wo
> > rd=1234567890). Which makes my boss/client unhappy.
> > As a band-aid fix, I'm turning all requests into POSTs, but that's kind
> of
> > "rude", as some sub-class servlets may behave differently in the case of
> > POST than GET. (I can't think of a reason why; generally, I either
> > implement only POST b/c the servlet's action is not idempotent, or I
> > implement doGet and then make doPost simply call doGet. But LoginServlet
> > will be sub-classed by other developers, and I can't constrain them this
> way.)
> > One potential workaround is to define a doPost() method in LoginServlet
> > which either calls doGet(Request, Response) or simply redirect to
> > HttpServletRequest.getRequestURI() + "?" +
> > HttpServletRequest.getQueryString(). That would solve the situation when
> a
> > sub-class only implements doGet(), but not if it implements doGet() and
> > doPost() differently.
> >
> > Can anyone think of a work-around or alternative design pattern that
> would
> > still allow for the benefits of the system outlined above?
> >
> > Some people have spoken about the single-servlet model where that
> servlet
> > takes a parameter (or PathInfo) specifying an alternate servlet/object
> to
> > invoke. That might do as well in this case, but I'm not really
> > familiar/comfortable with that kind of system.
> >
> > Thanks in advance,
> > LT
> > --
> > The nice thing about being a cynic is that I enjoy being wrong.
> >
> >
> __________________________________________________________________________
> _
> > 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
>
> __________________________________________________________________________
> _
> 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
>
> __________________________________________________________________________
> _
> 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
___________________________________________________________________________
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
