That certainly would work, but it seems to go against good practice on a number of levels, most importantly is that the same code (am i logged in ? continue : go to login with a possible callback) gets duplicated in every page. I'd hate to force every page to do this and I definitely don't want to use a base page, some pages may not need a base class at all...
There are options that could make that work, I just don't see one I like. Thanks, -Mike On 3/23/06, Ryan Holmes <[EMAIL PROTECTED]> wrote: > It might be worth the effort to refactor your code so that security > checks are performed in the pageValidate() method. This is a pretty > standard approach and benefits in part from the fact that the target > page is already loaded when creating callbacks, etc. There's a simple > example in the VLib app. > > Each page class can create different types of callbacks (e.g. external > vs. direct, varying parameters, etc.) by defining a createCallback > method() in your base page class and overriding it as needed. > pageValidate() invokes any security checks and calls createCallback() to > hand a callback to the login page. > > I used this approach with Acegi recently. It took a little work to > replace the Acegi web filters, but the result is nicely integrated and > easy to use. > > -Ryan > > > Mike Snare wrote: > > I'm writing an interceptor to perform authentication checks and I'm > > contributing the interceptors to the major services (direct, asset, > > page, etc). If the user is not logged in I throw a > > PageRedirectException to the login page. If the page the user is > > trying to view implements a marker interface specifying that it can be > > returned to after login (I'm specifically not using external callback) > > then the 'nextPage' attribute of the login page is set before throwing > > the exception. The Login page currently redirects back to the desired > > page by name. > > > > It's working fine, except for a couple of issues that may or may not > > be fixable. That's where I need some expert help. > > > > The interceptor is invoked before the service method, so the page > > hasn't really been set up yet. The interceptor actually has to look > > at the request parameters to find the name of the page we are going > > to. It can't just call infrastructure.getRequestCycle.getPage. > > Another side effect of this early call is that none of the properties > > on the page have been set up yet, so even if I wanted to use > > ExternalCallback for pages that take parameters, I'm worried that I'm > > going to run into problems when the page actually gets called back > > because the ExternalCallback would be created in the interceptor (not > > in the page) and so the service parameters would have to be added > > as-is, in no particular order. When the page gets called back it > > would have no way of knowing how to extract the parameters from the > > object array b/c it didn't specify the order. > > > > If I could somehow force the page to initialize itsself I could make > > it implement a method that knew how to take its parameters and create > > a object array from them and return it. Can I force the class to > > implement itsself prior to the call to service()? > > > > Anyone have any ideas? My goal is to have as little work necessary > > for individual page developers to get this to work for them. > > > > It's almost 11 here, so pardon me if I'm not being particularly clear... > > > > Thanks, > > -Mike > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
