Ron, Like everything else, I don't think there's a simple answer. Generally, I stick to the main point of a GET request (querying info) and a POST request (posting data). I generally use service() for any processing which is used by all types of requests. So my code typically has general code (such as user checking) in the service method, and then calls doGet() or doPost() to handle the request. But, if your servlet responds the same for GET and POST requests, there's really no reason to use the individual handlers. Kito D. Mann [EMAIL PROTECTED] [EMAIL PROTECTED] Friday December 17, 1999 02:11 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (bcc: Kito Mann/PSG/Prudential) Subject: Re: [design] set of servlets that require login i don't even overload doPost() and doGet() anymore in my servlets - i go straight to service(). is that bad if i don't treat posting vs. getting differently? i can't imagine why, but in case anyone has a good reason not to do it that way i'd be happy to hear it. ...............ron. -----Original Message----- From: Danny Rubis <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Thursday, December 16, 1999 3:13 PM 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&passw o >> 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
