Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
janfabry opened this issue Nov 2, 2017 · 6 comments

Comments

@janfabry
Copy link

janfabry commented Nov 2, 2017

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 [email protected], but if Bob follows the link and creates his account as [email protected], 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
Copy link
Author

janfabry commented Nov 2, 2017

Another issue is that allauth will assume the stashed e-mail address ([email protected]) also belongs to the user, so he will end up with [email protected] as a primary and [email protected] 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 [email protected] and then forwarded to [email protected] to handle this stuff, Bob would end up with [email protected] as his main address.

@clokep
Copy link
Contributor

clokep commented Nov 2, 2017

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

@gotexis
Copy link

gotexis commented Aug 14, 2018

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
Copy link
Contributor

jeromecc commented Feb 13, 2020

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):

  • an attacker guesses an email that was used to send an invitation
  • the invitee click the link but does not register
  • the attacker goes to the registration page and uses the email address to register

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
Copy link
Contributor

You can see an implementation here. Very basic. 6 lines of code.
master...DocTocToc:secure

@bplovell
Copy link

bplovell commented May 4, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants