> > 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 only an example of > request.env.http_referer... Maybe if I search for "_next" I'll find > some explanation that doesn't use 'referrer' but a similar term... >
As I said, I believe the documentation needs improvement here. It appears the navbar _next parameter isn't documented in the book yet (was probably added sometime after the last book revision). We should also add an option to the navbar helper allowing you to disable the _next behavior for particular actions. I'm not sure what else you want. the > only other use of "_next" is on page 346 (free PDF) where _next fields > are described as "the URL to redirect to after a successful > <operation> record." THAT'S WHAT I WANT, YAY! Woo! Hoo! No? Oh well. > It would be really nice if things with similar names had similar > meanings... 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? > > The issue is not with auth.settings.register_next, but with the > > auth.navbar() helper. The navbar helper always adds the current page URL > as > > the _next var in the register link, so if you use the navbar to get to > the > > registration page, you will be redirected back to the page from which > you > > clicked the link. > > Unless of course you set auth.settings.login_next, in which case, no, > it doesn't; the automatically generated auth links use > auth.settings.login_next and not the page from which I clicked the > link. > I believe I only mentioned the register link, so not sure what you're disagreeing with here. Yes, though, it does appear that the navbar does not do the same thing with the login link, and I'm not quite sure why -- I think it probably should (and I mentioned that in my comment on the Google Code issue). > > But I still don't see a bug with auth.settings.register_next. > > I don't really care if the cause of the bug is the navbar function or > something else. Since auth.settings.register_next is a passive > variable, of course that can't BE the bug. > Of course. But you implied there was a bug in the way auth.settings.register_next was being handled in the register() function (i.e., that it is always ignored, which is not the case). It is in fact being handled as intended. Moreover, your suggested fix (to have auth.settings.register_next take precedence within the register() function) would actually break the intended behavior. It's important to identify the real problem before attempting a fix. > > The intended behavior is that a referrer takes > > precedence, and auth.settings.register_next is the default when there is > no > > referrer -- and that's how it works. We now just need an easy way to > prevent > > the navbar from automatically adding a referrer. > > And to make it treat all the auth.settings' _next fields uniformly (or > document why it shouldn't). > I agree, though probably not for logout, as the current page may no longer be accessible after logout. Anthony
