The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.On latest CVS (13 March I believe) and core CVS, new users receive 'authenticated user' role even if they haven't clicked the validate link in their email. This is with option "Set password & Immediate login" and a 'non-authenticated' role set to my own role called "pre-authenticated".
I can see that the user has the permissions of a normal authenticated user because after registring and before clicking the link in their mail they have access to permissions which are only selected for the role "authenticated user".
Looking in db.user_roles I note there are no instances of rid = 2 (authenticated user) contrary to what you might expect. Killes in IRC informs me this is a new 'feature' in core HEAD as of around mid March, because all users are expected to have a rid of 2 thus to save performance. Thus this mucks up logintoboggan functionality, as all 'users' are automatically now considered to be 'authenticated' and thus logintoboggan cannot override this.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | logintoboggan_roles2.patch.txt | 7.21 KB | aaron |
| #2 | logintoboggan_roles.patch | 7.22 KB | jakeg |
Comments
Comment #1
jakeg commentedFor the change in core HEAD that causes this bug see http://drupal.org/node/44379 . So rid=2 is no longer inserted into the users_roles table at all. Webchick saw the potential problem too and gives a suggestion: http://drupal.org/node/44379#comment-67027 which sounds like a good one.
Comment #2
jakeg commentedokay, i've rolled a patch. I tried with all my might to make a patch which doesn't change the functionality of loggintoboggan, but since the core patch talked about above, it just wasn't possible to remove the role 'authenticated user' from a user.
Thus this patch means rather than having a pre-authenticated role, you have the normal 'authenticated user' and then a higher level is the 'verified user' (or whatever you like to call it) role, meaning they've verified that their email is valid.
Thus you give 'authenticated user' permissions to do some stuff, and 'verified user' additional permissions. A verified user.
NOTE: suggestion to core - change 'authenticated user' to 'registered user' and then rename this one 'authenticated' or 'verified' user.
Comment #3
aaron commentedLooks good. Only I would have the message for when users set their passwords but aren't immediately logged in as well. Here's a revised patch with that simple change. Also look at http://drupal.org/node/57623 for a message that also goes on the user/view page.
Comment #4
webchickYeah, something like this needs to get committed, as the "pre-authorized role" is compeletely dead in the water in 4.7.
Will try and test later...
Comment #5
rubenk commentedI've installed the patch in 4.7 and in CVS. Works in both (4.7 was patched by hand). HOWEVER, this doesn't seem like an optimal solution. The authenticated role priveleges are inherited by all of the other roles. I would like to be able to take advantage of this. Does someone have a suggestion of another way to take advantage or CORE functionality while still satisfying the concept of a pre-authenticated role?
Comment #6
hunmonk commentedit looks like the best way to attack this is to strip a user of the authenticated user role on the fly if they aren't verified yet. i think this would more closely preserve the intended functionality, as well as make the upgrade path from 4.6 easier.
if anybody wants to take a crack at that approach, please feel free. :) if not, i'll get to it after i've gotten the rest of the issue queue under better control...
Comment #7
hunmonk commentedfixed in 4.7 and HEAD. the best solution was to dynamically revoke the auth role for users who are still in the pre-auth role. this leaves all the benefits of the old order, not to mention making the upgrade from 4.6 -> 4.7 much easier.
Comment #8
(not verified) commented