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

Proposal: allow sending invitations to the same email address multiple times #253

Open
Flimm opened this issue Jun 14, 2024 · 3 comments
Open

Comments

@Flimm
Copy link
Contributor

Flimm commented Jun 14, 2024

I wanted to see what you thought about this, before I attempted to implement it.

If a user tries to create an invitation to an email address, they may receive this error, if another invitation exists with the same email address:

AlreadyInvited User has a valid, pending invitation

or:

AlreadyAccepted User has already accepted an invitation

They may also see this error, if there is a user account with that email address:

UserRegisteredEmail This email is already registered by a site user

The problem with these errors is that they are potential security vulnerabilities. If I invite a user at a certain email address, I may not want that information leaked to other users as they send invitations. Likewise, if I sign up to a website using a certain email address, I may not want other users to work out that my email address was used to register an account on the website.

Here is another problematic scenario: a user may accept an invitation, and then subsequently, delete their account. They cannot be invited again to the website on the same email address, because of the error AlreadyAccepted.

There is also a usability problem. Users may want to send an invitation email more than once. Maybe the last email was sent two years ago, and the invitee cannot be expected to root through their email archives to find it. These errors prevent invitation emails from being sent multiple times.

@ivanov17
Copy link

ivanov17 commented Jun 16, 2024

I think there needs to be a choice here because it may depend on the site specific rules. For example, an application might allow any existing user to invite new ones. However, the site administration may not want to see the user again if they was blocked.

On the other hand, this is an unreliable way to block someone. Anyone can use mail aliases, plus-addresses and other email accounts. They won't have any problem if someone wants to invite them using another address. Therefore, this is more of an administrative problem than a technical one.

This may prevent from unintentional mistakes, but on the other hand, this should only be applied to locked accounts and not to others. I'm not sure if this package is supposed to provide such a feature.

@Flimm
Copy link
Contributor Author

Flimm commented Jun 17, 2024

Website administrators might want to block a person from being invited again, that does sound like a valid feature request. django-invitations doesn't provide a feature to block people from being invited, nor am I proposing that feature in this GitHub issue. Are you saying we should only retire the AlreadyInvited, AlreadyAccepted and UserRegisteredEmail errors, if we also implement at the same time a feature to allow admins to block certain email addresses?

@JoGorska
Copy link
Contributor

  1. Re potential vunrability: User tries to create invitation they get error pointing them why he can't create invitation. I agree it is a vunrability, but these errors are very informative, it is good to know "why" for debugging.

I would assume that the user who has the right to send out invitations has higher privileges and would not abuse the functionality to work out other users' emails.

  1. Invite already accepted, but User deleted. The developer would have to handle this currently in their project. If user is deleted - find Invite and delete it. If we have a field "invitee" linked to user, than we could cascade and delete Invite after invitee is deleted.

  2. Re-send invite if send long time ago - yes that would be so useful!

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

3 participants