We logintoboggin to allow users to be logged into their site immediately after registering. We also use this module to force all users to change their password after registering.
New users receive a welcome asking them to validate their account. However, because this module acts on init, and that gets in before logintoboggin is able to validate the email addresses, users get instantly redirected away from the validation url (eg, user/validate/809/1361485476/9huQTwrCr-RJyfPLryhaik3BTvoPxpgRGLu4rfhYldA) and sent to their edit profile page. So, they never get properly validated. The the same is true of the core email validation process at /user/reset/*.
This module should not do the force redirection when on these paths so that users can properly validate/activate their accounts.
Comments
Comment #1
mrfelton commentedComment #3
mrfelton commentedtypo.
Comment #4
mrfelton commentedThey also need to be able to log out!
Comment #5
mrfelton commentedFollowing on from #1936688: Do not attempt to redirect users when called from php cli, POST, or system/ajax, I'm adding a couple moe exclusions to this list for php cli and ajax callbacks. Ultimately, as there are actually quite a few exclusions needed, I'd suggest that these should be extracted out into a provate function, as well as potentially providing a hook for other module to add to the exclude path list.
Comment #6
mrfelton commentedMarked #1936688: Do not attempt to redirect users when called from php cli, POST, or system/ajax as a dupe.
Comment #7
mrfelton commentedSlightly updated versions of the patch to also allow ajax urls for filefields, which can be attached to the user profiles and displayed on the user edit page. Without also excluding these paths from the redirection rule, the filefield widgets do not work correctly.
Comment #8
mrfelton commentedYet another exclusion needed here. This really needs to be abstracted into something that other modules can easily extend.
Comment #9
fastangel commentedI think that other solutions is create a hook. Then other modules can implement this hook and return url to exclude. Into module we can implement this hook for exclude core paths (system,....)
What do you think?
Comment #10
erikwebb commentedI think a hook works, or maybe a variable that has a sane default. I'm not sure we can expect modules to implement this hook consistently.
Comment #11
mrfelton commented> I'm not sure we can expect modules to implement this hook consistently
Why would modules implement this hook any less consistently that any other hook?
Comment #12
erikwebb commentedGood point. Other than Drupal core, what other modules create specific problems here?
Comment #13
coltrane#8 patch looks good to me but here's a hook approach since for instance I'm pretty sure Bakery won't want to force redirect during bakery auth.
Attached patch moves the arg() checks to new hook 'password_policy_expire_init_run'. I'm not in love with the name. Suggestions welcome. Also, should start an api.txt or api.php file documented hooks like this and how they're used.
Comment #14
erikwebb commentedI'm thinking
hook_password_policy_expire_url_exclude().Comment #15
erikwebb commentedRenaming hook.
Comment #16
deekayen commented