Danny Rubis wrote:
>
> Hey!
>
> Hans, could explain what you mean by this >>>>>>
> ... login form, you can also save the method.
> >>>>>>>
The original proposal was to save the name and value of all parameters
as hidden fields in the login form, i.e. dynamically generate HTML like:
<input type="hidden" name="foo" value="bar">
My suggestion to get around the problem with POST and GET (see original
message below) was to also save the method used for the original request
in the same way, i.e.
<input type="hidden" name="origMethod" value="GET">
And then invoke the originally requested resourse as a POST or GET
(with a redirect) from the authentication code depending on the
value of origMethod (see below for details).
> 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
--
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
