Private Nodes are viewable by users who have not yet confirmed their e-mail

[XFuser]

Hello,

If a user registers and upon registration is automatically assigned a User Group that gives them permission to view a Private Node, then they are able to view the Private Node before confirming their e-mail.

Users who are not "valid" with a confirmed e-mail should not be considered "full members" and should therefore not be able to view Private Nodes until they confirm their e-mail.

Please fix this issue.

Thank you.

 

[Mike]

The users who have registered but have not yet confirmed their e-mail have the "Registered" usergroup assigned yet their User State shows as non-Valid, so they are incorrectly receiving the "Registered" permissions before actually confirming their e-mail.

The registered group is correct. Users are never put into the unregistered group. The code forces the permissions of non-valid users to be that of the unregistered group when the user browses regardless of what the permissions "should" be.

True, but the "Never" permissions of the "unregistered / unconfirmed" usergroup would trump all other permissions, correct?

Never would trump, yes, but it's a moot point since users shouldn't ever be explicit members of that group.

 

[XFuser]

The registered group is correct. Users are never put into the unregistered group. The code forces the permissions of non-valid users to be that of the unregistered group when the user browses regardless of what the permissions "should" be.

OK, so if I'm understanding you correctly, when a user is in the non-valid state, they will receive the permissions of the "unregistered / unconfirmed" usergroup regardless of the usergroups it has assigned, is that correct?

Furthermore, they are never actually placed in the "unregistered / unconfirmed" usergroup, they just have their permissions limited to that group while they remain in the "Registered" usergroup but non-valid User State, is that correct?

If the above are correct, then I'm confused again because if those are case, then how are non-Valid users viewing a Private Node that Unregistered/Unconfirmed users do not have permission to view? (Keep in mind that their Secondary usergroup does give them permission, but they are non-Valid users.) Does that mean that to keep non-Valid users from viewing Private Nodes, we would have to explicitly set the "View" permission of the "unregistered / unconfirmed" usergroup in every Node to "Never"?

 

[Paul B]

Have you confirmed it from your own account by changing the state and then logging in?

Or are you just looking at the activity record for the users?

 

[Martok]

how are non-Valid users viewing a Private Node that Unregistered/Unconfirmed users do not have permission to view? (Keep in mind that their Secondary usergroup does give them permission, but they are non-Valid users.)

This is definitely not the case. I have a private node on my site. I'm an admin, a moderator and in several user groups and have all permissions on my site. As soon as I change my state from Valid to Awaiting email confirmation then I can no longer see the private node.

 

[XFuser]

Have you confirmed it from your own account by changing the state and then logging in?

Or are you just looking at the activity record for the users?

I did a "Test Permissions" of a User who is 1) "Registered", 2) has the secondary Usergroup assigned (that allows them to view Nodes), and 3) in the "Awaiting E-mail Confirmation" User State, and I could see all non-Admin Private Nodes during that test even though unregistered users cannot view any Nodes.

This is definitely not the case. I have a private node on my site. I'm an admin, a moderator and in several user groups and have all permissions on my site. As soon as I change my state from Valid to Awaiting email confirmation then I can no longer see the private node.

I replicated this and got the same results as you and all the Private Nodes disappeared, so the User State actually seems to be working correctly and as one would intuitively expect as I described in my opening post.

Does that mean there's a bug with the "Test Permissions" feature?

 

[Paul B]

This explains how the test permissions function works: https://xenforo.com/help/permissions/

Your user state was never set to invalid when you tested.

 

[XFuser]

This explains how the test permissions function works: https://xenforo.com/help/permissions/

Your user state was never set to invalid when you tested.

Mine was not, but the user whose permissions I was testing was. One would intuitively expect to see what the User you are testing sees when Testing their Permissions. I would suggest either taking into account the tested user's User State during the Permissions Testing or at the very least adding another caveat in the link you provided that mentions that the User State of the target user is ignored when testing the permissions.

Thanks for everyone's help, I really appreciate it.

 

[TPerry]

I've provided an example of why users should not be granted any access by XF until they become valid by confirming their e-mails. For the opposite perspective, could someone please give me an example of why users should be granted any access at all before validating their account when e-mail confirmation is enabled? I'm trying to understand in what kind of scenario that would be useful. Thanks.

The thing is... you have to get OUT of the mindset of how permissions/user groups work with other scripts.
The simple solution is you assign that node to be viewable to ONLY a specific user group.
You run a promotion that promotes use the user based upon their user state


They don't receive that user state until they have validated their email... once they do that, then they have access to the node since they are promoted to that user group.