You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tim Shadel <ti...@zserve.com> on 2003/05/21 20:25:29 UTC
Custom login & POST replay
We have a custom login mechanism that uses a Filter to put auth info
into the Session. We have several servlets that are protected by this
Filter. Some respond differently to GET than they do to POST (don't
ask, it's historical and being abolished...but it's still there).
How can I make the following work?
Original
HTTP POST --------> Filter
|
| Not Logged In
|
<-------- Send login.jsp
Login.jsp
HTTP POST --------> Filter
|
| Log User In
|
Replay Original
HTTP POST --------> Process
|
| Log User In
|
<------------------------------ Results of Original POST
I've looked at a few ways to do this:
1. If the request is a GET, just use the Query String, and forward()...
That works.
2. Translat the POST to a GET, and just do #1. Might work, but see the
part about some servlets acting differently with POST than they do with GET.
3. Save the HttpServletRequest object, and feed that to forward()
instead of the current request. Won't work. The object's a facade that
guards against such misuse (Tomcat clears the request when it's done
with it, so even if you put the facade in the session, the underlying
request object is gone on the next time around).
4. Create a new request object. I assume you can't just load up the
Tomcat classes because of ClassLoader restrictions, unless your webapp
is marked as privileged="true". In any case #3 & #4 seem like Bad Ideas.
The problems come in trying to recreate the POST, since
* the servlet expecets certain items to be available with the
request.getParameter() call.
* Users spend a long time filling out a form (often typing in a
textarea), and the back arrow won't restore their work (another
issue altogether). They don't like losing their work.
* I'm not sure if RequestDispatcher.forward() honors the
request.getMethod() when calling the next resource. If my login
form submits using POST, and I forward(), will the container call
my servlet's doPost() method?
If so, can I fake it this way:
- Throw ALL parameters on the Query String (including a LONG
message??)
- forward() using the Login request
This might make all parameters available from getParameter(),
it might call the doPost() method on my servlet.
I can try this last idea, and see what happens, but any info on if/how
this may work would sure be helpful.
I've seen chunks of these threads:
http://marc.theaimsgroup.com/?l=tomcat-user&m=104483095805178&w=2
http://marc.theaimsgroup.com/?l=tomcat-user&m=105338088407197&w=2
which try to get around limitations with FORM based authentication.
These (and other) limitations of that mechanism make me a bit leery to
drop our application authentication. So I'd prefer an answer that lets
us keep that for the time being.
TIA,
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Custom login & POST replay
Posted by Bill Barker <wb...@wilshire.com>.
I assume that you've looked at o.a.c.authentictor.FormAuthenticator, which
attempts to do much the same thing. In this case, it implements something
close to #4.
"Tim Shadel" <ti...@zserve.com> wrote in message
news:3ECBC499.4050006@zserve.com...
> We have a custom login mechanism that uses a Filter to put auth info
> into the Session. We have several servlets that are protected by this
> Filter. Some respond differently to GET than they do to POST (don't
> ask, it's historical and being abolished...but it's still there).
>
> How can I make the following work?
>
>
> Original
> HTTP POST --------> Filter
> |
> | Not Logged In
> |
> <-------- Send login.jsp
>
>
>
> Login.jsp
> HTTP POST --------> Filter
> |
> | Log User In
> |
> Replay Original
> HTTP POST --------> Process
> |
> | Log User In
> |
> <------------------------------ Results of Original POST
>
>
> I've looked at a few ways to do this:
>
> 1. If the request is a GET, just use the Query String, and forward()...
> That works.
>
> 2. Translat the POST to a GET, and just do #1. Might work, but see the
> part about some servlets acting differently with POST than they do with
GET.
>
> 3. Save the HttpServletRequest object, and feed that to forward()
> instead of the current request. Won't work. The object's a facade that
> guards against such misuse (Tomcat clears the request when it's done
> with it, so even if you put the facade in the session, the underlying
> request object is gone on the next time around).
>
> 4. Create a new request object. I assume you can't just load up the
> Tomcat classes because of ClassLoader restrictions, unless your webapp
> is marked as privileged="true". In any case #3 & #4 seem like Bad Ideas.
>
>
>
> The problems come in trying to recreate the POST, since
>
> * the servlet expecets certain items to be available with the
> request.getParameter() call.
>
> * Users spend a long time filling out a form (often typing in a
> textarea), and the back arrow won't restore their work (another
> issue altogether). They don't like losing their work.
>
> * I'm not sure if RequestDispatcher.forward() honors the
> request.getMethod() when calling the next resource. If my login
> form submits using POST, and I forward(), will the container call
> my servlet's doPost() method?
>
> If so, can I fake it this way:
> - Throw ALL parameters on the Query String (including a LONG
> message??)
> - forward() using the Login request
> This might make all parameters available from getParameter(),
> it might call the doPost() method on my servlet.
>
>
> I can try this last idea, and see what happens, but any info on if/how
> this may work would sure be helpful.
>
>
> I've seen chunks of these threads:
>
> http://marc.theaimsgroup.com/?l=tomcat-user&m=104483095805178&w=2
> http://marc.theaimsgroup.com/?l=tomcat-user&m=105338088407197&w=2
>
> which try to get around limitations with FORM based authentication.
> These (and other) limitations of that mechanism make me a bit leery to
> drop our application authentication. So I'd prefer an answer that lets
> us keep that for the time being.
>
> TIA,
>
> Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org