For those interested, in trunk, auth.navbar() now takes a referrer_actions
argument. If you do:
auth.navbar(referrer_actions=None)
It will no longer add referrer URLs to the query strings of any of the
navbar links, so any auth.settings._next settings will take
precedence in that case. If you
>
> > Seems to me this has precisely the same meaning (though in a different
> > context). In the context of Auth, register_next is the URL after you
> > register, and in the context of Crud, create_next is the URL after
> > submission of a create form. What's the problem?
>
> By "precisely th
On Mon, Jul 2, 2012 at 11:03 AM, Anthony wrote:
> Seems to me this has precisely the same meaning (though in a different
> context). In the context of Auth, register_next is the URL after you
> register, and in the context of Crud, create_next is the URL after
> submission of a create form. What's
>
> I searched the book (free PDF) for "referrer".
> The term "referrer" only occurs once, where you quoted above. No
> explanation given, no mention of a "_next" var in the URL.
> Then I searched for "referer" thinking, OK, maybe the explanation I'm
> looking for just has a typo, but found on
On Mon, Jul 2, 2012 at 1:03 AM, Anthony wrote:
> Here's what the book says:
> These must point to the URL you want to redirect your users to after the
> various possible auth actions (in case there is no referrer):
>
> Notice the highlighted text. The _next URLs are default redirect URLs when
> th
>
> > I don't think it's a bug, per se, but the behavior (and documentation)
> could
> > be improved.
>
> ??? The documentation is quite direct and clear that you can set
> auth.settings.register_next to control where the user goes next. It
> doesn't work. It's not even clear that it can work
On Sat, Jun 30, 2012 at 11:11 AM, Anthony wrote:
> I don't think it's a bug, per se, but the behavior (and documentation) could
> be improved.
??? The documentation is quite direct and clear that you can set
auth.settings.register_next to control where the user goes next. It
doesn't work. It's no
>
> 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._next
> fields which are of the last resort, and it is hard to see under what
> circumstances the auth.se
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
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 _n
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 th
On Sat, Jun 30, 2012 at 2:37 AM, I wrote:
> and that _next seems to override anything I set in my model for
> auth.settings.registration_next.
Typo, I should have written:
and that _next parameter seems to override anything I set in my model
for auth.settings.register_next
-=D
12 matches
Mail list logo
