:)
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
