:)
Thanks for your reply.
It's a little more complicated than that :)
Our client has very complex requirements. I already created an
"ExtendedAuthenticationProcessingFilter" to handle some of these requirements :)
But the problem with POST is quite tricky.
I discovered its cause, which is as following:
The problem occurs when I try to access the page containing the form while not
being logged-in.
This causes the ExceptionTranslationFilter to save the request on the session,
under the ACEGI_SAVED_REQUEST_KEY. This SavedRequest has (of course) the method
GET.
Then the login form is presented, and after login the SavedRequestAwareWrapper
does the following:
SavedRequest saved = (SavedRequest)
session.getAttribute(AbstractProcessingFilter.ACEGI_SAVED_REQUEST_KEY);
if ((saved != null) && saved.doesRequestMatch(request, portResolver)) {
savedRequest = saved;
session.removeAttribute(AbstractProcessingFilter.ACEGI_SAVED_REQUEST_KEY);
..
}
This code looks perfectly ok, because the SavedRequest is removed from the
session.
But the problem is that after this filter, on the next request or somewhere, I
can't determine where and why, the SavedRequest re-appears on the session!!
I actually tried to debug through the Apache Tomcat code (I use Tomcat 6), and
still could not determine why the SavedRequest re-appears.
For now I have found the simple workaround of using some URL for the initial
GET that displays the form, and a different URL for the action="..."
method="POST".
Sorin
On Mon, 2008-04-21 at 15:07 +0200, olivier nouguier wrote:
> yap,
> I use to observe the same (odd) behaviour with standard j2ee form
> login configuration ... but with acegi you can
> "alwaysUseDefaultTargetUrl" to avoid this (setting default target to
> "/init.action" or a like).
> hih
>
>
>
> On Mon, Apr 21, 2008 at 12:36 PM, Sorin Postelnicu
> <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> Can anyone confirm to me that if I have a secured page and
> this page contains a form with method="post" (and action=the
> same page), then the POST will not work?
> The behaviour that I noticed is that the POST is converted to
> a GET when going through the filter chain. Is this true?
> And is there any way to solve this?
> If anyone else encountered this problem, thank you for any
> solution or suggestion you can give me.
>
> Sorin Postelnicu
>
>
>
>
> -
> This SF.net email is sponsored by the 2008 JavaOne(SM)
> Conference
> Don't miss this year's exciting event. There's still time to
> save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ___
> Home: http://acegisecurity.org
> Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>
>
>
> --
> "Quand le dernier arbre sera abattu, la dernière rivière asséchée, le
> dernier poisson péché, l'homme va s'apercevoir que l'argent n'est pas
> comestible"
> - proverbe indien Cri
> -
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ___ Home:
> http://acegisecurity.org Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
