Closed (won't fix)
Project:
Registration codes
Version:
7.x-1.0
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
18 Nov 2011 at 18:30 UTC
Updated:
7 Jan 2014 at 15:18 UTC
Jump to comment: Most recent
Comments
Comment #1
IronWorker commented[edit: I retract the assertion that this double uses regcodes: The regcode is actually only used in one place due to the way the function is called, so no, this won't double use the regcode
However, it doesn't do dynamic regcodes because the validate event is checking for regcodes before the _user_presave even fires which would actually create the regcode to validate against.
There needs to be some code in there that fires a validate event(s) from dynamic (and other) codes in coupling with the lookup of regular regcodes (find any of them is valid) during the form validation.
Once validated and the user is being inserted, then the codes can actually be generated and the main module of regcode used to actually use it.
].
Comment #2
Xomby commentedWould it be possible to just re-order the code?
I'm just installing this module, so if I run into this issue I'll post back with a workaround (everything is life or death for a client, except cutting checks...)
Comment #3
IronWorker commentedit'll probably take a little more than that... This was predicated on D6, it looks like, and some of the calls don't happen in the same place. A person could edit up the code a tad but it'll take a little to do it.
Basically, the premise of the code is that it validate the code and then inserts it (as a static code) before the rest of regcode actually uses it.
The problem here is that regcode has apparently evolved a little since this was written....
Not that it can't get fixed but that it isn't going to work as it's written in D7
Also I'd like to see it rewritten a bit to handle plugin algorithms for dynamic codes too along with some custom outcomes. For instance, I've got a requirement where the code itself tells the system what to do with the user.... the code has a lexical meaning both for validity and what to do when inserting the user.
Comment #4
Xomby commentedThis would make a lot of sense. But predictability in the regcode itself would be a security concern, once someone realized the pattern, they'd be able to, via trial and error, predictably register an account with a potentially higher privilege.
OK so how about a user-defined or random(per system) salt added to the code and then the whole thing encrypted or encoded to obfuscate the original meaning. At least then it would look random again...
Comment #5
znerol commentedI've done the port to D7. I did not care too much about dynamic registration codes because the current implementation is really dangerous IMHO.
I removed all calls to regcode dynamic functions throughout the other modules. In order to make dynamic regcodes work, I suggest to implemet
hook_form_FORM_ID_alterfor theuser_registerform. There you just put in your custom#validateand#submitcallbacks. Refer to the main regcode module to get an idea on how to do that.Comment #6
aidanlis commentedThis never really got any traction so I'm just going to remove it from the 7.x branch unless someone finishes it up.