jazzband / django-invitations

Generic invitations app for Django
GNU General Public License v3.0
568 stars 166 forks source link

Trigger invitation acceptation even if different e-mail address signs up with allauth #87

Open janfabry opened 7 years ago

janfabry commented 7 years ago

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

janfabry commented 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.

clokep commented 7 years ago

It seems correct that both emails end up on the account, but I suppose it could be confusing.

gotexis commented 6 years ago

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!

jeromecc commented 4 years ago

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.

jeromecc commented 4 years ago

You can see an implementation here. Very basic. 6 lines of code. https://github.com/bee-keeper/django-invitations/compare/master...DocTocToc:secure

bplovell commented 4 years ago

The app doesn't pre-fill the email field in for me. Does it only do this if you enable ACCEPT_INVITE_AFTER_SIGNUP?