Hold on -
getting away from the code / implementation for a second - what do you want
to happen from the person's end:
requires_login => login()
login() -> fail retry login() (which should have a link for registration);
-> fail(limit) -> login_failed()
-> succeed -> login_next()
registration -> succeed: ????
.... someone finish this....
On Fri, Jul 10, 2009 at 8:14 PM, mdipierro <[email protected]> wrote:
>
> what about this?
>
> auth.settings.registration_onaccept=lambda form: auth.is_logged_in()
> or redirect(URL(r=request,f='login'))
>
>
>
> On Jul 10, 7:51 pm, Jonathan Lundell <[email protected]> wrote:
> > On Jul 10, 2009, at 5:34 PM, mdipierro wrote:
> >
> > > I do not like the idea of a paremeter dependent on another parameter.
> > > What do other people think?
> > > I think people should propably override this variable anyway.
> >
> > The problem is that there's no way to override the variable(s) to get
> > the desired (by me, anyway, but I think it's logical) distinction
> > between being logged in or not.
> >
> > That's crucial, isn't it? Either the user is logged in and ready to
> > go, so we go to login_next (regardless of whether we got there via
> > login or registration-and-auto-login), or the user is not logged in
> > and we don't.
> >
> > The problem is that registration_next takes us to the same place
> > regardless of whether the registration resulted in a login or not.
> >
> > Perhaps there should be three nexts: login, registration+login,
> > registration+pending.
> >
> >
> >
> > > Massimo
> >
> > > On Jul 10, 7:10 pm, Jonathan Lundell <[email protected]> wrote:
> > >> On Jul 9, 2009, at 3:05 PM, mdipierro wrote:
> >
> > >>> You are right. Uploading your fix to trunk. Thanks.
> >
> > >> There's a remaining problem, I think.
> >
> > >> The current behavior (after this patch) is to log in after
> > >> registration and go to index. The problem is that (and I think that
> > >> Fran brought this up), after registration you really want to go to
> > >> login_next if you're logged in, but to registration_next if you're
> > >> not
> > >> (which would be the case if you're using email verification).
> >
> > >> Making them both index fixes simple apps like welcome, because its
> > >> login_next (index) doesn't really care if you're logged in. But if
> > >> you've got (as I do) login_next that uses (say) auth.user.id, you'll
> > >> get a ticket if you go there after a registration that doesn't do a
> > >> login.
> >
> > >> I think the behavior should be: go to login_next after a successful
> > >> login *or* after a registration that performs a successful login. Go
> > >> to registration_next if the registration process went OK but for some
> > >> reason (like email verification) the user isn't logged in.
> >
> > >> On a somewhat related matter: there ought to be a way to request the
> > >> sending of another email verification. If the message gets lost for
> > >> some reason, there's no way for the user to deal with it, excepting
> > >> maybe trying to get some administrator's attention to manually edit
> > >> the user table.
> >
> > >>> Massimo
> >
> > >>> On Jul 9, 4:09 pm, Jonathan Lundell <[email protected]> wrote:
> > >>>> On Jul 9, 2009, at 1:48 PM, mdipierro wrote:
> >
> > >>>>> You should not ne already logged in after registration. That is
> > >>>>> not
> > >>>>> default behaviour
> >
> > >>>> That's how welcome is working. This is immediately after
> > >>>> registering:
> >
> > >>>> pastedGraphic.tiff
> > >>>> 57KViewDownload
> >
> > >>>>> On Jul 9, 3:11 pm, Jonathan Lundell <[email protected]> wrote:
> > >>>>>> From the pov of a novice...
> >
> > >>>>>> The default auth.settings.register_next (user/login) is confusing
> > >>>>>> in
> > >>>>>> that after registration you're already logged in, but user/
> > >>>>>> login is
> > >>>>>> asking for a login again. f=index might be a better choice.
> >
> > >>>>>> Yes, I know it's easy to override, but the confusion starts
> > >>>>>> with a
> > >>>>>> new
> > >>>>>> user playing with the welcome application.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
