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
-~----------~----~----~----~------~----~------~--~---
