You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by tony kerz <to...@sbcglobal.net> on 2005/12/07 06:10:52 UTC
obtaining "real" url after navigation rules
i'm having an issue attempting to apply the spring based acegi security
layer to myfaces.
basically, acegi seeks to apply a servlet filter to each page navigated
to and apply a set of security rules to either grant or deny access to
that page.
the issue that i'm encountering is that the servlet filter always seems
to be one url behind the page that i'm on (and thus the desired security
functionality is sadly lacking).
i tried reversing the order of the extensions filter and the acegi
filter and that had no effect.
any insight appreciated.
in lieu of a direct solution to this issue, my next strategy may be to
attempt to grab the "correct" url programatically and pass it to over to
acegi, so any suggestions on ways to go after that via faces context
would also be welcomed.
i already tried looking in HttpServletRequest obtained from the external
context, and sadly, it was one url behind as well :(
thanks,
tony.
Re: obtaining "real" url after navigation rules
Posted by Andrew Robinson <an...@gmail.com>.
You can get the correct JSF view ID inside of a phase listener in the
before render response. At this point in the lifecycle, you should
also be allowed to forward to a login page.
-Andrew
On 12/6/05, tony kerz <to...@sbcglobal.net> wrote:
> i'm having an issue attempting to apply the spring based acegi security
> layer to myfaces.
>
> basically, acegi seeks to apply a servlet filter to each page navigated
> to and apply a set of security rules to either grant or deny access to
> that page.
>
> the issue that i'm encountering is that the servlet filter always seems
> to be one url behind the page that i'm on (and thus the desired security
> functionality is sadly lacking).
>
> i tried reversing the order of the extensions filter and the acegi
> filter and that had no effect.
>
> any insight appreciated.
>
> in lieu of a direct solution to this issue, my next strategy may be to
> attempt to grab the "correct" url programatically and pass it to over to
> acegi, so any suggestions on ways to go after that via faces context
> would also be welcomed.
>
> i already tried looking in HttpServletRequest obtained from the external
> context, and sadly, it was one url behind as well :(
>
> thanks,
> tony.
>
>
>
>
>