Members getting flagged for manual review but auto approved anyway

[Clover13]

So recently I started getting emails on manual review required (spam defense) but the member gets approved automatically anyway.  

It appears there are two Spam Defense log entries for the same account.  The first flags a 3 (manual review required) and the second flags a 1 (auto approval).  However, I am not sure why there are two checks?

[Marc Stridgen]

I would need a couple of examples so I can take a look at this for you. There should indeed only be one check

[Clover13]

1 hour ago, Marc Stridgen said:

I would need a couple of examples so I can take a look at this for you. There should indeed only be one check

Thanks Marc, sent you a couple examples in PM.

[Marc Stridgen]

Please check that these users have not registered through tapatalk. I suspect given they can register using that method, this may well be what is causing the problem.

[Clover13]

9 hours ago, Marc Stridgen said:

Please check that these users have not registered through tapatalk. I suspect given they can register using that method, this may well be what is causing the problem.

Is there anything in the account logs that indicates the registration method used?  It's not in the member's account activity (in the AdminCP).

[Jim M]

34 minutes ago, Clover13 said:

Is there anything in the account logs that indicates the registration method used?  It's not in the member's account activity (in the AdminCP).

I'm afraid, you would need to ask TapaTalk to obtain that definite information. This is available to them via the developer SDK should they want to use it, just they would need to use it for it to show up there.

[Clover13]

@Jim M

Sorry it's been awhile, I did reach out to Tapatalk and followed their recommendation of setting up a secondary group (that has no actual additive access) to help identify those creating accounts via Tapatalk.

It turns out a recent case was related to creating a new account via Tapatalk and somehow triggering multiple (4) Spam checks.  The same IP with a different email first triggered two 4s and was blocked correctly, then a new email with that same IP then triggered a 1 and then a 2 (requires manual review).  However that first 1 looks like it created the account and the spammer could have posted had I not noticed it and banned them.

Still unclear where this issue is or why it's happening but I suspect it's with the create account workflow via Tapatalk?  I'll await your thoughts on it.

Here's a couple screenshots

 

Edited May 12, 2022 by Clover13

[Marc Stridgen]

Its something you would need to bring up with them. Unfortunately, we cannot assist with 3rd party applications

[Clover13]

6 hours ago, Marc Stridgen said:

Its something you would need to bring up with them. Unfortunately, we cannot assist with 3rd party applications

OK I'll follow-up with them, but at least others know what might be a contributor should they see similar behavior and also support Tapatalk for their site

[Marc Stridgen]

No problem 🙂 

[Clover13]

@Marc Stridgen

Here is their reply:

Quote

Thank you for contacting Tapatalk!     Sorry, I'm sorry I don't quite understand your problem. The spam method is not controlled by Tapatalk, please check the related settings in your forum ACP.     Regards,  Tapatalk Support Team 

So the question now is what is the workflow of account creation and spam check and who controls what parts of that?  I'm assuming Tapatalk just sends an API call to create an account, and per their response, IPS triggers a spam check based on that call (not Tapatalk), so why would two different spam checks be called?

[Jim M]

1 minute ago, Clover13 said:

So the question now is what is the workflow of account creation and spam check and who controls what parts of that?  I'm assuming Tapatalk just sends an API call to create an account, and per their response, IPS triggers a spam check based on that call (not Tapatalk), so why would two different spam checks be called?

I'm sorry that you are being bounced back and forth but you would need to further explain the problem to Tapatalk. They are responsible for any interactions their application has with the core registration system. If there is a fault in the core, this would be reproducible on our end but I'm afraid, it is not so it is simply how Tapatalk is interacting with it. If you are able to reproduce this in the core registration system with Tapatalk disabled, please let us know.