Open janfabry opened 7 years ago
Another issue is that allauth will assume the stashed e-mail address (bob@example.com
) also belongs to the user, so he will end up with bob@example.com
as a primary and bob.lastname@example.com
as a secondary e-mail address. This may or may not be what you want (so I'm not sure whether it should be considered a bug, in allauth or this package).
Example: in case the original invitation was sent to a general address like info@example.com
and then forwarded to bob@example.com
to handle this stuff, Bob would end up with info@example.com
as his main address.
It seems correct that both emails end up on the account, but I suppose it could be confusing.
Thanks @janfabry, I just had the same question.
Actually, I was trying to do exactly what you did, setting up the user in some way after account creation. But I am new to Django signals. If you won't mind could you please share the code for the handling code for post_account creation?
I would appreciate any help!
I think a solution would be to store the invitation in the session (in the AcceptInvite view) and retrieve this actual invitation in the accept_invite_after_signup signal handler. The invite_accepted signal might then need to be changed as well: don't just send the e-mail address of the original invitation, but the e-mail address used to accept it as well.
Hi! Used as it is, this app may pose security or DDOS problems because it just redirects to a registration page according to a url. Nothing prevents a random user to just go to the registration page and register. As suggested by @janfabry, using Django's session to store the invitation key could allow a registration app to link an anonymous user with her invitation (the app could check that the Invitation key exists and that the email used to register corresponds to the key). Another problem is this scenario:
If the registration flow doesn't include another email verification step (which is cumbersome because the invitee has to check her email once already):
It would be great to have the possibility to add the key in the session and to send it with the signals along with the email. Another solution without using session is to append the invitation key to the redirection url as a parameter. Thanks.
You can see an implementation here. Very basic. 6 lines of code. https://github.com/bee-keeper/django-invitations/compare/master...DocTocToc:secure
The app doesn't pre-fill the email field in for me. Does it only do this if you enable ACCEPT_INVITE_AFTER_SIGNUP?
If you enable
ACCEPT_INVITE_AFTER_SIGNUP
, the invitation to accept is looked up based on the e-mail address used to complete the signup. Because this field is editable (but pre-filled), it's possible the user enters a different e-mail address, and the original invitation will not be found and never marked as accepted.In my case I have post-acceptance triggers that will give a user rights to edit a specific object. So user Alice will invite user Bob with the e-mail address bob@example.com, but if Bob follows the link and creates his account as bob.lastname@example.com, his invitation will not be marked as accepted and he can not get the necessary permissions.
I think a solution would be to store the invitation in the session (in the
AcceptInvite
view) and retrieve this actual invitation in theaccept_invite_after_signup
signal handler. Theinvite_accepted
signal might then need to be changed as well: don't just send the e-mail address of the original invitation, but the e-mail address used to accept it as well.