Posted some issues. http://code.pinaxproject.com/tasks/task/512/ http://code.pinaxproject.com/tasks/task/513/ http://code.pinaxproject.com/tasks/task/514/ http://code.pinaxproject.com/tasks/task/515/ http://code.pinaxproject.com/tasks/task/516/
I'll assign myself and get to work, now that I have a good understanding of what is wanted. On Oct 27, 2:47 am, Nick Retallack <[email protected]> wrote: > On Oct 27, 12:09 am, Brian Rosner <[email protected]> wrote: > > > > > > > On Oct 27, 2009, at 12:27 AM, Nick Retallack wrote: > > > > On Oct 26, 10:16 pm, Brian Rosner <[email protected]> wrote: > > >> On Oct 26, 2009, at 8:17 PM, Nick Retallack wrote: > > > >>> 1) Wouldn't it be nice if verifying your email address logged you in > > >>> automatically? > > > >> -1. I definitely don't like this. As you mention, it isn't even > > >> possible unless we modify authentication. I want the action taken by > > >> emailconfirmation to be atomic. Letting emailconfirmation handle > > >> authentication too sounds like a really bad idea not only from a > > >> security standpoint, but from an implementation standpoint too. > > > > Yeah but it's the expected behavior. Having to verify your email > > > address is annoying enough. It should be able to log you in and > > > complete the registration. > > > You apparently are the one with the requirement to require e-mail > > confirmation. Pinax by default doesn't enforce that. I disagree that > > it is expected behavior. I simply do not want to support this use case > > in Pinax. > > > > Also, this could be made into a non-default configuration setting, so > > > you can warn people about the security risks in some nearby comments. > > > Having to document potential security risks is something I'd prefer to > > avoid. If this functionality is important to your requirements there > > isn't much stopping you from implementing it yourself. It isn't > > anything *I* want to support in Pinax. > > Well you already have the ACCOUNT_EMAIL_VERIFICATION setting. This > setting sounds like a logical extension to me. Would you accept it if > I submitted a patch for this setting anyway? > > > > > > > >>> If you do go ahead and make the email confirmation log you in with > > >>> the > > >>> associated account, the confirmations become dangerous. You can't > > >>> leave stale ones around. Right now, I can keep refreshing this > > >>> email > > >>> confirmed page with the same confirmation key and it just confirms > > >>> it > > >>> repeatedly. I can even pull out old confirmation keys and they work > > >>> too. I suppose the keys expire eventually, but I think it would be > > >>> best if they were just deleted when they are no longer useful. When > > >>> an email is successfully confirmed, it should delete all the > > >>> associated confirmation keys. > > > >> Yep, I agree that upon confirmation that all keys associated to the > > >> confirmed e-mail address should be deleted. The current behavior is > > >> that you are allowed to re-send confirmation e-mails. A very likely > > >> situation where a user doesn't get them, but each time you re-send a > > >> new key is generated. This should be noted in the task you'll create > > >> for this issue. > > > > I'm not sure how those things are related. There's nothing wrong with > > > having multiple keys lying around while you're attempting to verify > > > your email address, because it's always possible that some of them > > > don't make it. They could also arrive in the wrong order, so new keys > > > shouldn't invalidate old ones. > > > Confirmation is only tied to one account. Invalidation of the old keys > > won't matter since you already performed the confirmation for the > > account you requested it for. I'm confused how you see invalidation of > > old ones an issue? > > Sorry, this whole bit is consistently confusing me. I was just asking > what your point was. It just seemed like a non-sequitur when you said > "Yep, I agree that upon confirmation that all keys associated to the > confirmed e-mail address should be deleted.", and then "The current > behavior is that you are allowed to re-send confirmation e-mails." > You can't re-send confirmations after the email address has been > verified either way, so this statement is not relevant to the notion > of deleting no-longer-useful confirmations. So I was just curious > what you were getting at here. > > > Keep in mind Pinax won't always depend on a username. Since we will be > > generating a unique hash for each account I don't mind producing a > > single e-mail as you suggest. > > Cool idea. I'll write that up. > > I'm intrigued by this idea that Pinax may not require usernames in the > future. Are there any plans in motion for that? > > > This is fine. All I am trying to get at is that we don't need to > > implement this feature to solve other bugs in Pinax. They are > > unrelated. Supporting [email protected] syntax will be a site specific > > requirement. If you want that, add it yourself. > > Ok. > > > > If you set ACCOUNT_EMAIL_VERIFICATION=True, you couldn't possibly be > > > logged in when the message is generated. You have to actually verify > > > your email address first. After you do that, you can log in, and at > > > that point you get this useless message that an email confirmation has > > > been sent. > > > Oddly enough I still wasn't able to reproduce. However, I see in the > > code what you mean. It doesn't make much sense unless you are > > authenticated after sign-up which is the case when e-mail is optional. > > This can definitely be fixed. > > Are you signing up a new account? When I do that with > ACCOUST_EMAIL_VERIFICATION on, by the time I actually log in, I get > these messages: > > Confirmation email sent to [email protected] > Successfully logged in as example. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Pinax Core Development" 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/pinax-core-dev?hl=en -~----------~----~----~----~------~----~------~--~---
