The basic use case is this: User clicks on a link that requires_login and gets redirected to the login page. After login the user is redirected to the original requested page.
Exceptions: - the login is outsourced to janrain - the login is outsourced to cas or other open-id - the login is not possible and the user must first register - after login is redirected to the intended page but the app logic finds this user has incomplete profile and redirects to profile editing (*) - what if the user is impersonating another user? (?) - the user is visiting a page that does not require login but LOADs a component that does (?) - the user is visiting a page that does not require login but LOADs a component that does - the user has another window open (**) (*) is not currently supported. (?) not sure if it works (**) worked with _next but not not with session._auth_next. On Sep 17, 10:06 am, Jonathan Lundell <[email protected]> wrote: > On Sep 17, 2011, at 7:51 AM, Massimo Di Pierro wrote: > > >> I also don't entirely understand this: > > >> def pop_next(self): > >> next = current.session._auth_next > >> if next and next.startswith(URL()): > >> next = current.session._auth_next = None > >> return next > > >> The startswith test: are we simply saying that if the startswith test is > >> met, then we're already at the destination, so don't redirect? > > > I guess it go both ways. > > > I am worried the new session mechanism may break when multiple windows > > are open, or when IFRAME and LOAD are used. I may have to revert this. > > It seems to me that there are two issues here. One is cleaning up the logic > to make it uniform, DRY and understandable. The other is deciding where to > put the next link (and doing proper validation of the URL). > > I understand (I think) the basic use case for @requires_login, I think. > > What's the use case for saving the return link in Auth()? > > Does it make sense to try to save a next link in cases like change-password? > Profile editing? > > I'm fine with reverting for now, but I really think that this logic is due > for a review and cleanup. Maybe starting with a spec: what are we really > trying to do? And how do these dynamic _next links relate to the various > next-URL links in auth.settings?
