[WMTech] Sticky Multiple Account Info

[WMTech] Sticky Multiple Account Info [Paid] 1.1.5

No permission to buy ($48.00)
Overview FAQ Updates (10) Reviews (6) History Discussion
@wmtech I've had to disable this as for some reason some people can't register when this is active, there are a fair number who can register. I do NOT have the deny registration for multiple accounts option ticked
 
Jim Boy said:
@wmtech I've had to disable this as for some reason some people can't register when this is active, there are a fair number who can register. I do NOT have the deny registration for multiple accounts option ticked
Click to expand...

This add-on does not tamper in any way with the standard XenForo registration, if the deny option is not checked. The detection and handling of detected multiple acounts runs in a totally different scope.

I cannot see any way registrations could be blocked by this add-on.

You may want to check your anti-spam or captcha options?
 
wmtech said:
I cannot see any way registrations could be blocked by this add-on.
Click to expand...
Except it does, I've looked in your code and I've found the bug, no biggy - the sort of oversight all coders make, but apparently your code is perfect so I must have imagined it.
 
  • Like
Reactions: Xon
Jim Boy said:
Except it does, I've looked in your code and I've found the bug, no biggy - the sort of oversight all coders make, but apparently your code is perfect so I must have imagined it.
Click to expand...

Of course no code is perfect and such a bug would warrant an immediate update. I forward it to the developers. Thanks.
 
Hello wmtech, interested in purchasing, but two things we would need before we could. Hopefully you would consider them.
First we'd need to be able to set the name of the standard cookie so existing cookies set by a different addon are identified.
Second we need the ability to allow pairs of users to be exempt from detection. See this post (by my senior admin) to see why: https://xenforo.com/community/threads/alter-ego-detector.60972/page-14#post-856880
 
Stuart Wright said:
Hello wmtech, interested in purchasing, but two things we would need before we could. Hopefully you would consider them.
First we'd need to be able to set the name of the standard cookie so existing cookies set by a different addon are identified.
Second we need the ability to allow pairs of users to be exempt from detection. See this post (by my senior admin) to see why: https://xenforo.com/community/threads/alter-ego-detector.60972/page-14#post-856880
Click to expand...

The first request (cookie name) can be done via custom work. I can send you a quote via PM if you like.

The second request is already possible. The permissions of this add-on allows you to exempt user groups or even single users from being detected. Exempted users are transparent to the system, so a secount user account of that person would be seen as a single user. If this user happens to have 3 accounts, the other two would be detected as multiple. Of course you can exempt any number of accounts you like.
 
wmtech said:
The first request (cookie name) can be done via custom work. I can send you a quote via PM if you like.

The second request is already possible. The permissions of this add-on allows you to exempt user groups or even single users from being detected. Exempted users are transparent to the system, so a secount user account of that person would be seen as a single user. If this user happens to have 3 accounts, the other two would be detected as multiple. Of course you can exempt any number of accounts you like.
Click to expand...
Thank you.
It's pairs of accounts which have to be exempted. Not single ones. I don't want to use usergroups to achieve this as it's too unwieldy.
 
Stuart Wright said:
Thank you.
It's pairs of accounts which have to be exempted. Not single ones. I don't want to use usergroups to achieve this as it's too unwieldy.
Click to expand...

I understand the problem, as I've read the post you linked. Since our add-on works completely different than the other add-on that post is from, it is fully sufficient to place the banned multiple account (2nd account) into a no-detection group to reach the goal you need (3rd account of 1st account will be detected).

Another easy solution would be not to ban the 2nd account but to delete it. ;-)

We've a username protection add-on, you may also be interested in. It protects the reusage of deleted account names for a period you choose.
https://xenforo.com/community/resources/wmtech-deleted-usernames-protector.3066/
 
Last edited:
I'll only repeat what Stuart said above.

Marking any single account (via individual permission or by usergroup permission - same effect) does not properly cover the scenarios we envisage and will never be fully sufficient.

When a match between two accounts is detected, we investigate the relationship between the two and determine whether we will allow them to co-exist. So doing does NOT imply we will allow EITHER account to co-exist with anything other than the one reported and investigated. We may allow them to co-exist because they are genuinely different people - but that doesn't make EITHER of them individually exempt from our re-registration rule. We do NOT want reports suppressed against EITHER account individually; only against them both together.

Thus it is the precise, reported pair that is permitted; not either one.
 
@Harpers Tate @Stuart Wright

Thank you for your suggestion and the perfect explanation.

However this add-on is for information purposes about multiple accounts. You'll get a single notification for any account with one or more other accounts detected at the same computer (within a time period you can set, if you like forever). You can do what you like with this information. If you want to ignore it (because you "allow" those 2 accounts), you can simply do so. You won't get any further notification about those 2 accounts (as a pair) anyway. No need to set them to be "ignored".

But if any of those 2 accounts uses another account at the same computer, you'll get another notification about that account too.

The ignore setting should only be used for accounts which frequently use other accounts at the same PC. Like staff accounts or similar.

I know that other detection add-ons use a different "logic" and send alerts every time a double account user is detected even if it was detected before (so you may see a need to ignore a pair). This add-on works more professional in reliably giving you the information just once and it also will show you all multiple accounts of each account on it's profile page and in the particular users page in admin center for future reference.
 
Harpers Tate said:
Thus it is the precise, reported pair that is permitted; not either one
Click to expand...
Looking through the code it appears that the logic is based around sets of users, without limit on the number of users in the set.

So for example, A nd B live together, they use the same computer. This detects that, adds them both to the set and updates their individual tokens to the token of the set, which is derived as a md5 calculation of its member ids. This raises an alert, you investigate and take what ever action.

A goes to work, where he shares a pc with another user, C. This causes C to be added to the token set and alert is raised showing that C and A could be the same. You investigate and take action.

Later on, for some reason C logs into a a different computer that only A has ever logged into. No trigger happens because A, B and C are already part of the same token set.

So in summary, its not a case of comparing user1 to user2 (although that does happen), so much as comparing user 1 to the token set in the cookie on the pc

I could foresee a time where a very big forum snowballs, as when two members of different token sets use the same computer, then the then sets will merge, but that may never happen
 
Stuart Wright said:
So any pair of users is only ever reported once?
Click to expand...

Any user is just reported once. There is no need to report them more often.

Many of our customers do not even use any of the reporting/alert features. The add-on then silently collects all multiple account information in the background using several sophisticated detection technologies and records it.

Just after some user gets reported by another user (or another event occurs which triggers the manual inspection) those admins take a look at the data of the reported account and can see at a glance if (and if, how many) other accounts this person may be using (are -in fact- used at the same computer).

We all are aware that there are several legit reasons why more than 1 account may be used at the same computer. This is why the only automation tools this add-on provides are "Block registering a new account if the person already has one" and "put all multiple accounts in moderation". All further actions (ban, etc.) should be done manually.

Jim Boy said:
I could foresee a time where a very big forum snowballs, as when two members of different token sets use the same computer, then the then sets will merge, but that may never happen
Click to expand...

If this happens all those users are related, so the multiple accounts detection will be correct.

However you can set a time period after which an account is removed from a set of multiple users, if this account is no longer used with the same computer as the other accounts.

For example: A person visits his friend (both users at your forum) and uses the friends computer to log into your forum. This will trigger a multiple account detection, both accounts are alerted to you (if you like to be alerted) and recorded as multiple accounts. But this friend never again uses the foreign computer. So this "multiple" account will be removed from the records after the time period you set in your options (most use 30 days, we use 120 days). Both accounts will then be single again (except one of them uses a third account).

Again, this is a professional tool for professional forum websites. This has been created from a practical point of view by admins of large forums.
 
One minor annoyance - if you use a dedicated user to create threads in a forum upon detection, then that thread gets created using the same IP as the detected user, which means that if you look at the shared ips of detected users, they always include the dedicated user. Would be good if that can be avoided, perhaps by making the post IP 127.0.0.1
 
Jim Boy said:
One minor annoyance - if you use a dedicated user to create threads in a forum upon detection, then that thread gets created using the same IP as the detected user, which means that if you look at the shared ips of detected users, they always include the dedicated user. Would be good if that can be avoided, perhaps by making the post IP 127.0.0.1
Click to expand...

Thank you for reporting. We'll try to force this post to have a fake ip address. It shouldn't be too difficult.
 
Mouth said:
Is this going to be done? I've seen no release since it was suggested.
Click to expand...

This will be in our next release.
There is no date for it, since this is not really a bug, but a new feature.

There are several other reporting options and most of our customers do not even activate any reporting, since the information about multiple accounts is easily accessible at the user info pages in ACP and also in it's own tab at the public user profile pages.
 
Jim Boy said:
One minor annoyance - if you use a dedicated user to create threads in a forum upon detection, then that thread gets created using the same IP as the detected user, which means that if you look at the shared ips of detected users, they always include the dedicated user. Would be good if that can be avoided, perhaps by making the post IP 127.0.0.1
Click to expand...

Mouth said:
Is this going to be done? I've seen no release since it was suggested.
Click to expand...

Just for your information:
We just released a new add-on that is able to help you with your situation:
https://xenforo.com/community/resources/wmtech-hide-ip-essentials.4004/

If you like it and need it's features for another reason also, you may buy it and assign the reporting user the "Do not store any ip information" permission. Thus, preventing him from being detected by spam reports or ip searches.

We do not recommend buying that add-on just to solve your issue. We will add this ip masquerading feature in the next feature version of this add-on just as promised. ;-)
 
Been getting some server errors when using the spam cleaner since installing this add-on that we weren't getting before:

Code: 
Error Info
Zend_Db_Statement_Mysqli_Exception: Mysqli statement execute error : Duplicate entry '95772' for key 'PRIMARY' - library/Zend/Db/Statement/Mysqli.php:214
Generated By: TrixieTang, Yesterday at 2:14 AM
Stack Trace
#0 /srv/www/theadminzone.com/public_html/library/Zend/Db/Statement.php(297): Zend_Db_Statement_Mysqli->_execute(Array)
#1 /srv/www/theadminzone.com/public_html/library/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)
#2 /srv/www/theadminzone.com/public_html/library/Zend/Db/Adapter/Abstract.php(574): Zend_Db_Adapter_Abstract->query('INSERT INTO `xf...', Array)
#3 /srv/www/theadminzone.com/public_html/library/XenForo/DataWriter.php(1624): Zend_Db_Adapter_Abstract->insert('xf_user_ban', Array)
#4 /srv/www/theadminzone.com/public_html/library/XenForo/DataWriter.php(1613): XenForo_DataWriter->_insert()
#5 /srv/www/theadminzone.com/public_html/library/XenForo/DataWriter.php(1405): XenForo_DataWriter->_save()
#6 /srv/www/theadminzone.com/public_html/library/XenForo/Model/User.php(2612): XenForo_DataWriter->save()
#7 /srv/www/theadminzone.com/public_html/library/XenForo/Model/SpamCleaner.php(159): XenForo_Model_User->ban(95772, 0, 'Spam', false, NULL)
#8 /srv/www/theadminzone.com/public_html/library/XenForo/Model/SpamCleaner.php(27): XenForo_Model_SpamCleaner->_banUser(Array, Array, NULL)
#9 /srv/www/theadminzone.com/public_html/library/XenForo/ControllerPublic/SpamCleaner.php(53): XenForo_Model_SpamCleaner->cleanUp(Array, Array, Array, NULL)
#10 /srv/www/theadminzone.com/public_html/library/XenForo/FrontController.php(347): XenForo_ControllerPublic_SpamCleaner->actionIndex()
#11 /srv/www/theadminzone.com/public_html/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#12 /srv/www/theadminzone.com/public_html/index.php(13): XenForo_FrontController->run()
#13 {main}
Request State
array(3) {
  ["url"] => string(55) "https://theadminzone.com/spam-cleaner/jassigirls.95772/"
  ["_GET"] => array(1) {
    ["/spam-cleaner/jassigirls_95772/"] => string(0) ""
  }
  ["_POST"] => array(10) {
    ["action_threads"] => string(1) "1"
    ["delete_messages"] => string(1) "1"
    ["delete_conversations"] => string(1) "1"
    ["ban_user"] => string(1) "1"
    ["noredirect"] => string(1) "0"
    ["_xfToken"] => string(8) "********"
    ["_xfConfirm"] => string(1) "1"
    ["_xfRequestUri"] => string(50) "/threads/any-unmarried-players-so-sporting.131970/"
    ["_xfNoRedirect"] => string(1) "1"
    ["_xfResponseType"] => string(4) "json"
  }
}

Code: 
Error Info
XenForo_Exception: Error reporting to StopForumSpam: maintenance mode record processing deferred - library/XenForo/Model/SpamPrevention.php:294
Generated By: TrixieTang, Yesterday at 4:25 AM
Stack Trace
#0 /srv/www/theadminzone.com/public_html/library/XenForo/Model/SpamCleaner.php(46): XenForo_Model_SpamPrevention->submitSpamUserData(Array)
#1 /srv/www/theadminzone.com/public_html/library/XenForo/ControllerPublic/SpamCleaner.php(53): XenForo_Model_SpamCleaner->cleanUp(Array, Array, Array, NULL)
#2 /srv/www/theadminzone.com/public_html/library/XenForo/FrontController.php(347): XenForo_ControllerPublic_SpamCleaner->actionIndex()
#3 /srv/www/theadminzone.com/public_html/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#4 /srv/www/theadminzone.com/public_html/index.php(13): XenForo_FrontController->run()
#5 {main}
Request State
array(3) {
  ["url"] => string(59) "https://theadminzone.com/spam-cleaner/black-ops77899.95775/"
  ["_GET"] => array(1) {
    ["/spam-cleaner/black-ops77899_95775/"] => string(0) ""
  }
  ["_POST"] => array(10) {
    ["action_threads"] => string(1) "1"
    ["delete_messages"] => string(1) "1"
    ["delete_conversations"] => string(1) "1"
    ["ban_user"] => string(1) "1"
    ["noredirect"] => string(1) "0"
    ["_xfToken"] => string(8) "********"
    ["_xfConfirm"] => string(1) "1"
    ["_xfRequestUri"] => string(55) "/threads/materialsin-the-course-rex-lee-created.131973/"
    ["_xfNoRedirect"] => string(1) "1"
    ["_xfResponseType"] => string(4) "json"
  }
}
 
You must log in or register to reply here.

Similar threads

Mouth
  • Suggestion Suggestion
Multiple Account Detection
2
Replies
38
Views
9K
sgr
S
Mouth
Multiple Account Detection
Replies
15
Views
2K
Dan
Dan
Top Bottom