True, but you do not make them login again.
As long as you do not collect more information from the user (user id and
password) with each server request they initiate, you can store some
indication of user validity in the HttpSession object and check that each
time rather than using full-blown user/password verification. Verification
could take longer and be more demanding of resources.
If the HttpSession object exists but the indicator shows that the user is
not valid, then make them login. Otherwise (until the HttpSession expires
or you terminate it), you may assume that they are a valid user (to a point,
of course -- no one but the user controls keyboard input affecting their
HttpSession object).
If the HttpSession object does not exist, then make them login.
I'm not sure how other people do it -- I just keep a 'valid user' indicator
in the HttpSession object.
David Hildebrandt
-----Original Message-----
From: Emuleomo, Olu (PME) [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 17, 1999 12:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [design] set of servlets that require login
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
___________________________________________________________________________
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
