On 8/30/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> exactly. iauthstrategy is geared more towards declarative security and more
> towards components not pages. if your usecase does not match then doing the
> check in the base page's constructor is the way to go - clean and simple.
> thats why we
exactly. iauthstrategy is geared more towards declarative security and more towards components not pages. if your usecase does not match then doing the check in the base page's constructor is the way to go - clean and simple. thats why we have all those RestartResponseAtFoo exceptions :)
-IgorOn 8/
On 8/30/06, [EMAIL PROTECTED] Imam <[EMAIL PROTECTED]> wrote:
> Why dont you forward all these requests to a dummy page where
> you can take your decision making rather than depending on the
> authorization strategy solely.
>
> Inside the page you can handle requests such that the user is forwarded
Why dont you forward all these requests to a dummy page where you can take your decision making rather than depending on the authorization strategy solely.Inside the page you can handle requests such that the user is forwarded to a
sign in page and after successful sign in he is taken to the origi
I have a bunch of pages that I have mounted so that they are reachable
as /Foo.html?id=123. No big deal and works fine. But, I need to
protect these pages; I need people to bookmark them and return to
them, showing a login box in between if no session is active.
The usual recipe for protecting pag
