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.
>
>
>
>
>