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.
On Jul 11, 3:40 pm, Jonathan Lundell <[email protected]> wrote: > On Jul 10, 2009, at 7:57 PM, Yarko Tymciurak wrote: > > > > > > > On Fri, Jul 10, 2009 at 9:41 PM, Jonathan Lundell > > <[email protected]> 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 > >> <[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 -~----------~----~----~----~------~----~------~--~---
