On Sep 16, 2011, at 9:32 PM, Massimo Di Pierro wrote: > OK. So I followed the advice and rewrote all the next logic in trunk > (for Auth, not Crud) to use sessions. > > I tested with normal login, janrain and cas. It seems to work. Yet if > you can test it too would be best. > > there are two weird cases (and they were weird before): > - app A redirect to CAS provider app B. user does not have account in > app B and needs register. app B does not redirect to app A > - user tries to visit page in app A that requires login, after login > the app forces a redirection to edit profile, app A does not redirect > use to original requested page > > PLEAE CHECK THIS! There are subtleties.
It's certainly cleaner, anyway. One thing I don't understand (and it's not new, just relocated): +def is_relative(url): + return url and not url[0] == '/' and url[:4] != 'http' + I don't see how this can work, since the output of URL() typically (always?) starts with '/'. Doesn't it? > > On Sep 16, 8:44 pm, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Sep 16, 2011, at 6:28 PM, Anthony wrote: >> >> >> >> >> >> >> >> >> >>> On Friday, September 16, 2011 4:56:17 PM UTC-4, Massimo Di Pierro wrote: >> >>> should it just be? >> >>> if not self.user: >>> if not session._auth_next: >>> session._auth_next = URL(args=request.args, >>> vars=request.get_vars) >> >>> Won't the above store the first URL in the app visited by the non-logged-in >>> user in _auth_next? But don't we want it to be the first URL visited that >>> requires login? The user might start at /a/c/index (which doesn't require >>> login) and then go to /a/c/mysite (which does require login, so redirects >>> to the login page), but then would get sent back to /a/c/index instead of >>> /a/c/mysite after login, no? >> >>> if self.user and session._auth_next and not self.user and >>> session._auth_next.startswith(URL()): >>> next = session._auth_next >>> session._auth_next = None >>> redirect(next) >> >>> How does this improve upon the current _next logic, which limits _next to >>> relative URLs? Doesn't this code only store relative URLs from the current >>> app in _auth_next? Does this have something to do with the possibility of >>> login via CAS, so need to handle _next in __init__() rather than login()? >> >> Be nice to consolidate all this into one set of shared logic, using the >> session instead of the query string, with a uniform way of setting it and >> redirecting.
