Signup abuse detection and blocking

Signup abuse detection and blocking [Paid] 1.15.6

No permission to buy ($45.00)
Overview FAQ Updates (105) Reviews (21) History Discussion
@Xon , the readability of the approval queue is continuing to improve, but if I might offer a few suggestions?

Under Details:

Unless I am mistaken, the first line that starts with "Checking:" duplicates information above and to the left of that area. That line can be completely eliminated.

For the next few lines, a slightly more verbose approach would easily help us get through the information side of a check before getting to the "why this registrant is being moderated. I'd love to see something like:

[Registrant Name]’s ASN/ASN Owner is: [ASN #, ASN Owner]
[Registrant Name]’s hostname is: [Hostname/Hostname IP]
[Registrant Name] completed the registration form in [time]

This is all information about the registrant and would be great if it were grouped together.

Currently, in the middle of this information about the registrant is information on Shared IP and/or cookie matches. Would love to see those pushed down below the information and formatted more like:

Current:
Shared IP with rejected users ([Rejected User Name])
Suggested:
[Registrant Name] has a shared IP with rejected user(s) [Rejected User Name(s) with link to User Profile]


Current:
Moderating, Multiple account - Cookie, IP address: [User IP] - Username: [User Name], UserId: [User ID]
Suggested:
[Registrant Name] has a shared Cookie with user(s) [User Name(s) with link to User Profile]


Under Details, at the bottom, you have something like: Moderated. Direct rule selection and/or Rejected. Score exceeded ([Scores]>=[Score Limit])

However, shouldn't that part be under Action instead of under Details?

Also, I am noticing we have a number of these:
  • Total score: +1
  • Rejected. Score exceeded (+1 >= 1)
  • Moderated. Direct rule selection
If they are rejected, why do they end up in the moderation queue? Does moderation via direct rule supersede rejection due to score? If so, shouldn't the details be different?

I know this is a lot, but this is our most used and favorite tool of every add-on we have for Xenforo. It is crucial to how we manage and we are always looking for ways to make it faster/better/easier to understand.
 
Suggestion: Similar to IP check when registering if a banned user is matching, I'd suggest having an option for users in state "disabled" as well. Some users on our site ask to be deactivated just to re-register.
 
Small "bug": The tab entries in the admin cp do not contain any anchors. Default XenForo does (to directly link to a specific tab, for example #user-extras). "Login attempts" (from User Essentials, I think) and "Registration log" from this addon do not.
 
I'm having this error in the last version:

Code: 
LogicException: Attempted to set 'multiple_account_report' while a save was pending without forceSet src/XF/Mvc/Entity/Entity.php:575
Generado por: Tommaso Buscetta 27 Abr 2019 a las 14:16
Seguimiento
#0 src/XF/Mvc/Entity/Entity.php(548): XF\Mvc\Entity\Entity->set('multiple_accoun...', 1)
#1 src/addons/SV/MultipleAccountToThread/SV/SignupAbuseBlocking/Repository/MultipleAccount.php(125): XF\Mvc\Entity\Entity->__set('multiple_accoun...', 1)
#2 src/addons/SV/MultipleAccountToThread/SV/SignupAbuseBlocking/Repository/MultipleAccount.php(74): SV\MultipleAccountToThread\SV\SignupAbuseBlocking\Repository\MultipleAccount->threadCreator(Object(SV\SignupAbuseBlocking\Entity\LogEvent))
#3 src/addons/SV/SignupAbuseBlocking/Repository/MultipleAccount.php(225): SV\MultipleAccountToThread\SV\SignupAbuseBlocking\Repository\MultipleAccount->bumpReportEntries(Array, Object(SV\SignupAbuseBlocking\Entity\LogEvent))
#4 src/addons/SV/SignupAbuseBlocking/Repository/MultipleAccount.php(57): SV\SignupAbuseBlocking\Repository\MultipleAccount->processMultipleAccountDetectionInternal(Object(SV\SignupAbuseBlocking\XF\Entity\User), Array, 'register')
#5 src/XF.php(478): SV\SignupAbuseBlocking\Repository\MultipleAccount->SV\SignupAbuseBlocking\Repository\{closure}()
#6 src/addons/SV/SignupAbuseBlocking/Repository/MultipleAccount.php(58): XF::asVisitor(Object(SV\SignupAbuseBlocking\XF\Entity\User), Object(Closure))
#7 src/addons/SV/SignupAbuseBlocking/Repository/MultipleAccount.php(40): SV\SignupAbuseBlocking\Repository\MultipleAccount->processMultipleAccountDetection(Object(SV\SignupAbuseBlocking\XF\Entity\User), Array, 'register')
#8 src/addons/SV/SignupAbuseBlocking/XF/Pub/Controller/Register.php(49): SV\SignupAbuseBlocking\Repository\MultipleAccount->postRegistrationMultipleAccountDetection(Array)
#9 src/addons/SV/SignupAbuseBlocking/XF/Pub/Controller/Register.php(27): SV\SignupAbuseBlocking\XF\Pub\Controller\Register->reportMultipleAccountDetection(Array)
#10 src/XF/Pub/Controller/Register.php(420): SV\SignupAbuseBlocking\XF\Pub\Controller\Register->finalizeRegistration(Object(SV\SignupAbuseBlocking\XF\Entity\User))
#11 src/XF/Mvc/Dispatcher.php(321): XF\Pub\Controller\Register->actionRegister(Object(XF\Mvc\ParameterBag))
#12 src/XF/Mvc/Dispatcher.php(244): XF\Mvc\Dispatcher->dispatchClass('XF:Register', 'Register', Object(XF\Mvc\RouteMatch), Object(SV\SignupAbuseBlocking\XF\Pub\Controller\Register), NULL)
#13 src/XF/Mvc/Dispatcher.php(100): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(SV\SignupAbuseBlocking\XF\Pub\Controller\Register), NULL)
#14 src/XF/Mvc/Dispatcher.php(50): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#15 src/XF/App.php(2177): XF\Mvc\Dispatcher->run()
#16 src/XF.php(390): XF\App->run()
#17 index.php(20): XF::runApp('XF\\Pub\\App')
#18 {main}
 
I would like to be able to limit new users (or users with less than 10 posts) from posting links. I think this would fit perfectly in this add-on. 😀
I had this on XF1.5 and never had spam! That worked so good.
 
I've been considering something like that, but it is just a matter of timing. For the moment, my recommendation is to add http:// and https:// to the spam phrases which blocks new users from posting links in most places or throws it into the approval queue if a post/thread
 
This approach works but gives a lot of false positives for internal links. I hope this will be added in the future.
 
Xon said:
I've been considering something like that, but it is just a matter of timing. For the moment, my recommendation is to add http:// and https:// to the spam phrases which blocks new users from posting links in most places or throws it into the approval queue if a post/thread
Click to expand...
Yes, that will work. It's just more work to approve the correct posts. Like Alfa1 says it generates a lot of false positives.
 
Does "Show user registration records on user profile tab" only work for new registrations?
 
SeToY said:
Does "Show user registration records on user profile tab" only work for new registrations?
Click to expand...
I somehow managed to name that option wrong. It shows multiple account records not user registration records. Oops :(
 
You must log in or register to reply here.
Top Bottom