regardless of philosophy (and I pushed on the side of simpler = better, not buying that one time at registration is anything intolerably annoying to the user)...
but the point is to work out what you want, see all the pertinent "what is" questions, work them out, and then see what that leaves you with, and if you want to do it. patches are fine... worked out patches even better ;-) On Sat, Jul 11, 2009 at 4:26 PM, Jonathan Lundell <jlund...@pobox.com>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
