Hey!
Hans, could explain what you mean by this >>>>>>
... login form, you can also save the method.
>>>>>>>
Sans adieu,
Danny Rubis
Hans Bergsten wrote:
> "L. Turetsky" wrote:
> > [...]
> > 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
> > [...]
> >
> > 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.
> > [...]
> > 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.
> > [...]
> > Can anyone think of a work-around or alternative design pattern that would
> > still allow for the benefits of the system outlined above?
>
> I like the approach of preserving the original params as hidden fields,
> and I agree that you need to invoke the original request with the original
> method. Browsers treats POST and GET very differently when it comes to reloading
> the page, caching, etc. I haven't tested, but would something like this work.
>
> Besides saving all parameters as hidden fields in the login form, you can also
> save the method. The login form itself use POST to avoid the username/password
> in the URL. In the LoginServlet service method you do the authentication as
> before, but only call super.service() if the original request was a POST.
> If the original request was a GET, you do a redirect() with all the original
> parameters instead.
>
> Hans
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software http://www.gefionsoftware.com
>
> ___________________________________________________________________________
> 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
