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.
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?
But shouldn't we be setting _auth_next to None in the redirection case?
>
> On Sep 16, 8:44 pm, Jonathan Lundell <[email protected]> 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.
