Looking at tools/gluon.py again now that I have something working and
I am not in a rush, I notice something curious, lines 1226 and 1227:

        li_next = '?_next='+urllib.quote(self.settings.login_next)
        lo_next = '?_next='+urllib.quote(self.settings.logout_next)

So it looks as if maybe a 'more correct'? :-) solution might be to do
something similar with register_next being used to create the "_next"
parameter?

Nonetheless,  how Auth implements where to go next just seems
excessively tangled. There are next parameters to the methods, next
parameters in the URLs, and finally, auth.settings.<something>_next
fields which are of the last resort, and it is hard to see under what
circumstances the auth.settings.<something>_next fields will ever get
used (except for login_next and logout_next, as per the code quoted
above). It would be nice to understand what the use case(s) are for
all these next 'control points'...

At this point I still don't think I understand what's going on well
enough to submit a coherent bug report (I like to submit proposed
fixes too, but I'm not even close to thinking I can do that here).

Thanks for the help,
     -Doug



On Sat, Jun 30, 2012 at 10:13 AM, Anthony <[email protected]> wrote:
> Note, the first two options below will disable the _next functionality for
> all Auth actions. The last solution disables it only for the register
> action.
>
> Anthony
>
>
> On Saturday, June 30, 2012 10:12:50 AM UTC-4, Anthony wrote:
>>
>> Looks like auth.navbar() automatically adds the current URL as the _next
>> parameter so whenever someone clicks on an auth.navbar() link, after
>> finishing that action, they are returned to their original page. Also,
>> auth.settings.register_next (and similar) are only used as backup defaults
>> when there is no _next parameter in the URL (i.e., _next takes precedence).
>> Perhaps we should make it easier to override these two behaviors. For now,
>> though, I think you have a few options.
>>
>> First, right after you define auth, do:
>>
>> auth = Auth(...)
>> auth.next = None
>>
>> That should remove the _next value, which will allow the
>> auth.settings.register_next setting to take effect. Alternatively, right
>> before you define auth, you can remove _next from request.vars:
>>
>> request.vars._next = None
>> auth = Auth(...)
>>
>> You can also pass a "next" argument directly to the auth.register()
>> function (and other Auth functions):
>>
>> def user():
>>     if request.args(0) == 'register':
>>         form = auth.register(next=auth.settings.register_next)
>>     else:
>>         form = auth()
>>     return dict(form=form)
>>
>> Anthony
>>
>> On Saturday, June 30, 2012 2:37:36 AM UTC-4, Doug Philips wrote:
>>>
>>> I've been customizing how registration works for my app as a few of my
>>> app's users are getting confused by the registration verification
>>> email.
>>> Ok, so I will just have my app send them to a nice hand-holding
>>> explanatory page after they've submitted their registration
>>> information.
>>>
>>> According to The Book, "all" I have to do is set
>>> auth.settings.register_next to the URL I want, and I'm good to go.
>>> But I can't get that to work.
>>>
>>> (all line numbers are for
>>> https://github.com/web2py/web2py/blob/master/gluon/tools.py as of the
>>> time of this message)
>>>
>>> First off, it seems that the Register link I get from auth.navbar()
>>> always has a _next parameter appended to it,
>>> and that _next seems to override anything I set in my model for
>>> auth.settings.registration_next.
>>> Fine, I go into the navbar function of the Auth class in tools.py and
>>> delete the "+next" part of the registration link. (line 1242)
>>> That doesn't work, as for some reason I don't understand, the ?_next
>>> parameter in the URL is still present when the navbar is constructed
>>> from a regular page, but the ?_next parameter is (properly) missing
>>> from Register link when I first click on Login. Very odd to me.
>>>
>>> After trying a few more fixes, I decide that I do not understand how
>>> next processing is done for Auth.
>>> My fix is a huge hammer.
>>> I go into the register function and change lines 1983 and 1984.
>>> Actually I delete them and replace them with:
>>> next = self.settings.register_next
>>>
>>> I have no idea what the lines I deleted are trying to do, but they
>>> were keeping my expressed intent from working.
>>> Now my users are directed to the page I want after submitting their
>>> registrations, but I have no idea what else I have subtly screwed up.
>>> I don't even know if I should submit a bug report or if there is some
>>> other configuration I could do that would avoid having to make this
>>> code change.
>>> Help!
>>>
>>> -Doug

Reply via email to