On Jul 10, 2009, at 7:22 PM, Yarko Tymciurak wrote:
> 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: ????
Two ways to go, right?
registration -> succeed -> autologin -> login_next()
registration -> succeed -> requires_login ...
The current implementation does the former. But there's another case,
when there's an email verification:
registration -> pending -> ??
I was thinking maybe something like
registration -> pending -> registration_pending_next()
...where there *could* be, at least, a way for the user to request
another verification cycle.
The other possible case, from the user's POV, is
registration -> success (possibly via verification) -> autologin ->
firstlogin_next()
I can see that it's worth having these landing pages:
requires_login_or_registration (we don't know which, and should offer
both)
registration_pending
first_login_after_registration (implies autologin after registration)
login_failed (separate case for limit?)
There could be two ways to get to registration_pending, too: just
after the verification email is sent, as part of the registration
sequence, or any time thereafter if the user signs in with
registration pending (after all, they're in the database with a
password). That's the page were another verification email could be
sent.
WRT limiting login attempts, my preference would be to have a
(possibly increasing) delay between logins. You can try forever, but
eventually you have to wait maybe 10 seconds for another attempt. Of
course, enforcing that (or the limit) is slightly complicated by the
statelessness of http; it's not as if it's a VT100 or an ATM screen.
>
>
> .... 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
-~----------~----~----~----~------~----~------~--~---
