On Jul 11, 2009, at 2:17 PM, mdipierro wrote: > > Send me a patch of what you are proposing. If it involves only a > change in the register funciton than I am fine with it.
OK, I'll try to work one out. > > On Jul 11, 3:40 pm, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Jul 10, 2009, at 7:57 PM, Yarko Tymciurak wrote: >> >> >> >> >> >>> 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... >> >> The counterargument from the designer's pov is that we want to make >> the barrier to users as low as possible, consistent with security. To >> me, this implies not asking the user to redundantly log in after >> successfully registering (or completing the verification step). >> >> You're right, though, that there are two basic considerations: do we >> log a user in automatically after registration/verification? Second, >> how do we distinguish between the treatment of registration-pending >> and registration-successful (with no verification)? >> >> BTW, for the record, the current behavior if a registration-pending >> user logs in is to fail the login with a "Registration needs >> verification" flash. >> >> >> >> >> >>> ...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. >> >> Philosophically, I'd say that it's web2py's job to make life easier >> for the developer, and the developer to make life easier for the >> user. >> >> Autologin is a reasonable design choice, because it doesn't >> needlessly >> abuse the new user. Perhaps web2py should simply expose that decision >> to the developer in a straightforward way. Yes, it's a little more >> framework, but registration/login is highly visible, and worth >> getting >> right. And the autologin question is a policy decision that should be >> left to the developer. >> >> I could see overloading lost-password with registration-pending, but >> the retrieve-password page would have to change to make that clear. >> >> If we make autologin optional, we have these landing pages to >> consider: >> >> 1. failed login (no change) >> 2. successful login of registered user (whether explicit or automatic >> after registration/verification) >> 3. login with registration pending >> 4. first login (variation on #2) >> >> I don't have a big problem treating #3 as a failed login, as long as >> we add an option to re-send the verification. >> >> I'm not married to #4, but from a site designer's pov, I can see the >> desirability of having a first-login welcome page, maybe for >> orientation, etc. >> >> And regardless, there's a bug of sorts in the current implementation >> in that it doesn't distinguish between registration-with-autologin >> and >> registration-pending: both go to the registration_next page, and >> that's wrong. That's what Massimo's suggestion appears to address, >> though I confess some confusion about it (where does >> registration_next >> figure?): >> >> auth.settings.registration_onaccept=lambda form: auth.is_logged_in() >> or redirect(URL(r=request,f='login')) >> >> >> >>>> .... 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 -~----------~----~----~----~------~----~------~--~---
