The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.One and the same registration code can be used over and over again. This leads to multiple registrations on one invitation. Thereby the whole invite_only feature is broken. Adding
AND timestamp = 0
to the _invite_fetch_invite() sql query provides a workaround for the time being, as only unused codes are returned. Patch attached.
Have not yet tested too well, so feedback is appreciated.
Yours
Kai
| Comment | File | Size | Author |
|---|---|---|---|
| _invite_fetch_invite.patch.txt | 786 bytes | knseibert |
Comments
Comment #1
ajk commentedSeems like a reasonable fix to me, thanks :)
Commited: http://drupal.org/cvs?commit=52100 & http://drupal.org/cvs?commit=52101
Please note, I've recently released "official versions" and they are better to use than the dev snap-shots. I'm currently fixing a couple of other issues. When I'm done I'll do new releases and this fix will appear in those.
Comment #2
binodc commentedI need this feature for sending multiple invites to a group for joining as same role
Comment #3
knseibert commentedAnd you need them to all have the same reg_code? If so i could imagine an additional option on the settings page to adjust the sql query as needed. However this messes up the invite database table since only the last invitee using the reg_code is found there. If not why not send each member of the group an unique reg_code? Since invitee roles are depending on the inviters role that should work as well. ???
I personally think that a group feature should be implemented using a different approach and not by sharing a n unique reg_code.
Comment #4
ajk commentedreg_codes themselves are nothing special in themselves to be honest so re-cycling them is a valid option I suppose. But I agree that it should be a setting and a clear warning given that reg-codes can be re-used if set on (I say a warning because, as said, a reg_code can give away a role).
Do you two agree with that?
Comment #5
ajk commentedknseibert: off topic as your contact tab is disabled: would you like to be a co-maintainer of the module?
Comment #6
knseibert commented@4: Sounds good to me.
@5: AjK: You've got mail. Sorry for the disabled contact side. Should be up and running now.
Comment #7
smk-ka commented> reg_codes themselves are nothing special in themselves to be honest so re-cycling them is a valid option
I disagree with you here: when using invite together with userpoints, it would be possible to do automated registration using fake e-mail addresses to illicitly raise your points. A once generated reg code would be all you need.
The submitted patch is a first step in the right direction, but incomplete, as the timestamp is only checked when the form is presented (form_alter), but not when the submitted data actually arrives.
Therefore I've rewritten large parts of the invite module in an attempt to fix some outstanding problems, and I'd like to encourage you to test these patches and comment on them:
Comment #8
smk-ka commentedI've just committed a patch that fixes the last bit which could allow (maliscious) registration code reuse. I say the last bit, because the current code tends to treat these registration codes as being unique. The database scheme did ever so and the patch by knseibert adds to this behavior. And being able to mark this as fixed even cleans the issue queue some more... :)
--
Stefan Kudwien
www.unleashedmind.com
Comment #9
(not verified) commented