Users running a non-download version of Vanilla (pulled from github), on branch release/2019.016 or master from the last 2 weeks should upgrade to release/2019.017 or latest master for security reasons. Downloaded official open sources releases are not affected.
Vanilla 2.0.18 RC2 released
This discussion has been closed.
Comments
/conf/config-defaults.php
I found
$Configuration['Garden']['Registration']['ConfirmEmail'] = FALSE;
$Configuration['Garden']['Registration']['ConfirmEmailRole'] = 4;
I changed the first to 'TRUE' The Role to '3' (it says Member is 4 so presumabley , 'applicant' would be '3'
Then went to register in dashboard and clicked confirm email, it still only had 'Member', 'moderator', & Admin as choices, so I tried Member, created an account, and was signed in instantly and able to post instantly.
It did pop a system message saying 'You must confirm your email' BUT, it still let me post, whats the point? I presumed 'confirm email' meant you couldnt do anything, UNTIL, you confirmed your email?
The only permissions I allowed were 'sign in' as suggested by @Todd and 'veiw discussions'.
Under Registration, I tick the 'Confirm email, and 'New' appears in the dropdown.
Saved!
As before, Im instantly signed in and instantly able to post,. Do get sys message to confirm email.
Why was I signed in instantly and able to post instantly BEFORE confirming the email?
@Todd, did you mean 'DONT' give email confirmation role sign in permission ?
Does anything actually happen if they DONT confirm email?
It doesn't help to what I have read or not
The idea is to remove the permission to sign in to those who haven't confirmed their email yet. It worked for me, it even stopped a few Xrummers.
http://vanillaforums.org/discussion/17424/userlist-0.5-facebook-login-avatar-issue#Item_2
If I just nightly empty out the Activity table, will that horrible break vanilla? I see no other solution at this time.
https://github.com/vanillaforums/Garden/commit/747436011860d4f4fc99b3546f751b463547a480
In general usage of the site there are still queries hitting the activity table, and rather slowly at that. It's really the only source of entries in my mysql slow query log.
1. I assume it's the plugin rather than the core, The plugin should be adapted, instead of having to hack core files, or there will be hell upgrading to future vanilla releases.
2. its a minor inconvenience, certainly not critical, and given the turnaround on github issues, unlikely to be rectified before the next release is due anyway, which just might fix it.