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