I'm not clear on the use of the Non-authenticated role. The documentation says that a new user can be assigned the Non-authenticated role without email verification, and then be assigned to the "authenticated user" role once they follow the link in their welcome e-mail. In addition, "It is HIGHLY recommended that you set up a 'pre-authorized' role with limited permissions for this purpose".

However, my understanding is that all new roles inherit the permission of the "authenticated user" role. So how would assigning a user to a pre-authorized role have any fewer permission than assigning them to "authenticated user"?

Files: 

Comments

Status:Active» Fixed

auth user permissions are dynamically removed by logintoboggan when the user is in the pre-authorized role.

Thanks for the clarification. The reason I asked the question was that this was not working as expected on my install. Turns out I had Drupal Admin Menu installed which resulted in the pre-authorized role inheriting the permissions from the authenticated role as noted here: http://drupal.org/node/287448

Hi,

We are having the same sort of issue and we do NOT have Administration Menu installed.

We created a non-authenticated role of 'pending authentication'.
When a visitor to the site creates a login they automatically get both 'authenticated' and 'pending authentication' roles set.
My understanding is this should NOT happen with LoginToboggan setup with 'Set Password' checked.

In Public Registrations we do have the following set: "Visitors can create accounts and no administrator approval is required."

Any thoughts on what we may have setup incorrectly to be causing this behavior?

Thanks,
Karyn

@kcassio: i always recommend disabling all other contrib modules installed and seeing if you have the problem then. if not, start enabling them one at a time and see if you can find the culprit.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

Component:Documentation» Code
Status:Closed (fixed)» Needs review
StatusFileSize
new391 bytes

Sorry to re-open this one, but I found the problem with LT and thought I should post a patch. The issue is that LT does not reset the permissions cache after dynamically removing the 'authenticated user' role. Because of this, if any other enabled module calls user_access in its hook_init (as DAM does) and that module's hook_init runs before LT's hook_init, the permissions for the roles set by sess_read (which automatically sets the 'authenticated user' role when a user logs in) will be cached. If the permission cache is reset after the 'authenticated user' role is removed (which is what the patch does), all is well.

Note: it is also very important that you install a core patch, which fixes a subtle (and nasty) little problem with user_access noted here: http://drupal.org/node/275796 (which also has an attached patch) or else the fix won't work (in very subtle and hard-to-find way, believe me).

Q: Couldn't LoginToboggan also run in hook_boot() ?

I suppose that if LT implemented hook_boot() and called _logintoboggan_user_roles_alter($user), it would get ahead of any other module's hook_init (since they are called in a later bootstrap phase)... is there any reason why someone would call user_access in their module's hook_boot? If so, you would have the same problem again (if it got called ahead of LT's hook_boot).

Given that LT is dynamically altering user roles, and the whole purpose of the user_access permission cache reset feature is to (quoting the api doc) [reset] the user's permissions cache, which will result in a recalculation of the user's permissions. This is necessary to support dynamically added user roles, I think it is an appropriate solution (and it requires a minimal change to the existing LT code). If the official LT maintainers have a different opinion, that's fine by me.

@rickcoates, thanks, I'm successfully using your patch to successfully deal with this VERY SERIOUS problem in LT.
IMO LT needs to change its evil ways here, by allowing the assignment of a role of "post authenticated user".
Of course the real solution is to further develop Drupal core's notions of role hierarchies, beyond just "every user also has permissions of 'authenticated user'".

I'm using this patch to fix a serious bug in Login Toboggan. See http://drupal.org/node/319438#comment-1112176

Title:Quesiton on Non-authenticated roleReset user perm cache after removing auth role
Status:Needs review» Fixed
StatusFileSize
new918 bytes

new release available which includes this and other fixes: http://drupal.org/node/345001

there is no way to reset the user perm cache in 5.x, so the recommended solution for 5.x would be to change the module weight for any offending module that runs before LT so that it runs after LT.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.