On Fri, Jul 10, 2009 at 9:41 PM, Jonathan Lundell <jlund...@pobox.com>wrote:
> 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() > I've never seen a site with autologin (that I respected) - simpler reason? Confirm you got the password or whatever correct, so I think practically speaking just the next will be sufficient, simple, and useful: > > registration -> succeed -> requires_login ... > > The current implementation does the former. But there's another case, when > there's an email verification: > > registration -> pending -> ?? > If you go to registration -> succeed -> requires_login, then this is irrelevant; I (registrant) can check my email, and validate some other way, so that makes 2 of these go away without (I think) any end-user functionally adverse impact. > > I was thinking maybe something like > > registration -> pending -> registration_pending_next() > too many choices now; simpler == better, unless something compelling driving additional functionality... > > > > ...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() > Again - I'd can autologin.... > > I can see that it's worth having these landing pages: > > requires_login_or_registration (we don't know which, and should offer both) > I think just login, with 2 default links: - not registered? Register (link / button) - forgot password? click here (email id, re-up verification link or reset password - same function in one link) > > registration_pending > don't need (?) > > first_login_after_registration (implies autologin after registration) > I'd kill autologin... > > login_failed (separate case for limit?) > I would just lockout the userid which failed (12 minutes, something to prevent robot attacks) > > 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. > I see no registration pending needed; "forgot password" or "haven't confirmed registration" should be one functional link... > > 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. > Just timed lockout on a userid... not too tough. .... those are my thoughts.... on how to simplify... If you think I've gone too far, please speak up - but I don't think I did - I don't think more than this is necessary. > > > > > .... someone finish this.... > > On Fri, Jul 10, 2009 at 8:14 PM, mdipierro <mdipie...@cs.depaul.edu>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 <jlund...@pobox.com> 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 <jlund...@pobox.com> 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 <jlund...@pobox.com> 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 <jlund...@pobox.com> 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 web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
