You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use an explicit check !== true, but the value isn't cast to bool, so we're always comparing 1 !== true and always dispatch the event.
I suggest we add an Eloquent attribute cast to make this value an actual boolean.
Another option could be to just use !$this->is_email_confirmed since the column is non-nullable anyway.
Additional Context
This is not a big issue in itself, but if any extension wanted to use that event to configure something for the user account, it would be nice if the event didn't get triggered again. Since the user can essentially trigger it at will, a malicious example could be the registration event used to reset the user balance or strikes in an external database, which could be abused.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!
Bug Report
Current Behavior
The
Activated
event is dispatched every time an email change is confirmed, instead of just on the first email verification.Steps to Reproduce
Expected Behavior
The
Activated
event shouldn't be triggered again once the account is already activated.Environment
Possible Solution
The problem is here
https://github.com/flarum/core/blob/509adf228a18745b61a62b63cbdce3198ac17ff3/src/User/User.php#L368
We use an explicit check
!== true
, but the value isn't cast tobool
, so we're always comparing1 !== true
and always dispatch the event.I suggest we add an Eloquent attribute cast to make this value an actual boolean.
Another option could be to just use
!$this->is_email_confirmed
since the column is non-nullable anyway.Additional Context
This is not a big issue in itself, but if any extension wanted to use that event to configure something for the user account, it would be nice if the event didn't get triggered again. Since the user can essentially trigger it at will, a malicious example could be the registration event used to reset the user balance or strikes in an external database, which could be abused.
The text was updated successfully, but these errors were encountered: